I2P 개발자 회의 - 2007년 2월 6일

15:02 <jrandom> 0) 안녕 15:02 <jrandom> 1) 네트워크 상태 15:02 <jrandom> 2) Syndie 개발 상태 15:02 <jrandom> 3) 1월 버그 수확 대회 우승자! 15:02 <jrandom> 4) ??? 15:02 <jrandom> 0) 안녕 15:02 * jrandom 손을 흔든다 15:02 <jrandom> 주간 상태 노트가 http://dev.i2p.net/pipermail/i2p/2007-February/001333.html 에 올라갔습니다 15:03 <jrandom> 그럼 1) 네트워크 상태로 넘어가죠 15:03 <jrandom> 여기서는 덧붙일 게 많지 않네요 (보시다시피 ;) 15:03 <jrandom> 네트워크 상태와 관련해 제기할 게 있는 분? 15:04 <+void> 예전이 더 나았던 것 같긴 해요, 어떻게든... 15:04 <+void> 그래도 나쁘진 않아요 15:05 <jrandom> 이상하네요, 지난 일주일 정도 동안 stats.i2p 기준으로 우리의 빌드 속도가 다시 올라가고 있어요 15:05 <tethrage> 장기적인 패턴이 있나요? 15:06 <tethrage> (빌드 속도 변화에서) 15:07 <jrandom> 제가 보기엔 패턴이 고성능 routers의 용량과 연관되어 왔습니다만, 그건 네트워크를 매우 제한된 시각에서 본 거죠 (제가 아는 건 거의 공개된 정보뿐이라서요) 15:07 <tethrage> 알겠습니다 15:08 <tethrage> 도움이 될 만한 정보를 제공할 수 있을까요? 15:08 <tethrage> 그러니까 일반 routers에서 가져올 수 있는 정보 말이에요 15:08 <jrandom> 제 관점에서는, 딱히요 15:09 <tethrage> 그렇군요 15:09 <jrandom> (기본적으로 앞으로 나아가기 전에 몇 가지 코드 변경을 구현하기만 하면 됩니다) 15:10 <tethrage> 알겠어요 15:11 <jrandom> 좋아요, 1) 네트워크 상태에 대해 다른 얘기할 것 있나요? 15:12 <jrandom> 없다면, 2) Syndie 개발 상태로 넘어가죠 15:14 <jrandom> 보시다시피 여기서는 많은 일이 진행 중입니다 15:14 <+fox> <mk> 사소한 건데: 'signed by'를 'authorization'으로 바꾸는 게 어떨까요? 포럼, identities(아이덴티티), 서명 등 사이의 경계가 흐릿한 게 조금 찝찝하네요 15:14 <+fox> <mk> -d 15:15 <jrandom> 아, 좋은 생각이네요 15:16 <+void> mk: 포럼은 하나의 identity죠 :) 15:16 <+void> 그 반대도 마찬가지고요 15:17 <jrandom> 맞아요, 다만 이 묘한 이중성을 너무 드러내서 사람들을 혼란스럽게 하진 말아야죠 15:17 <+fox> <mk> 알고 있어요, 하지만 여전히 모호해요. 저는 이제 잘 이해하지만, 신규 사용자가 구분이 부족해서 혼란스러워할까 걱정돼요 15:18 <+void> 아하 15:18 <jrandom> 맞아요 - 사람들은 포럼과 identity를 다르게 인식하니까, 기대하는 대로 동작하도록 해야 해요 15:18 <+fox> <mk> 포럼이나 identity 관리에서 구현할 만한 다른 것 하나는 '작성자 x, 인가 y로 이 포럼에만 게시'처럼 명시하는 거예요. 그러면 혼동이 사라질 거예요. 새 글 작성 시 드롭다운조차 필요 없겠죠 15:19 <+fox> <mk> (키용 드롭다운) 15:20 <+void> 저는 항상 보이는 전역 identity 드롭다운이 더 좋아요 15:20 <+fox> <mk> 그러니까, 어떤 사람으로 게시하는지요? 15:20 <jrandom> 흠 15:21 <+fox> <mk> 그럴 수도 있지만, 항상 상단에 두는 것과 게시물에만 나타나게 하는 것 사이에 큰 차이는 없다고 봐요 15:22 <jrandom> 좋아요, 이걸 너무 깊게 파고들기 전에, 현재 syndie에서 다루지 않는 사이드 채널이 있어서 여러 identity를 연결할 수 있다는 점이 있어요 15:22 <+void> 하지만 identity는 게시 외에는 어디에도 쓰이지 않죠 15:22 <+fox> <mk> 무슨 뜻이죠? 15:23 <+void> 새 게시물 푸시? 15:23 <jrandom> 서로 전혀 연결되지 않는 identity가 필요하다면, 별도의 syndie 인스턴스를 실행해야 해요 - 서로 간에 동기화할 수 있고, 하나만 사용해서 다른 archive들과 pull/push할 수도 있지만, 로컬 archive에는 일부 identity만 접근할 수 있는 정보가 들어 있어요 15:23 <+fox> <mk> (큰 논의는 dev 포럼에 저장하는 게 좋다고 동의하지만, 이렇게 여러 사람이 한 번에 이야기하는 것도 좋네요) 15:24 <+void> 맞아요 15:24 <jrandom> 하지만 로컬 archive의 모든 identity가 그 정보에 접근할 수 있고, 그것을 바탕으로 행동하면(해당 키로 게시하는 등) 연결 가능성이 새어 나가요 15:25 <jrandom> 어쩌면 GUI를 통해 이 모든 걸 투명하게 달성할 방법을 찾을 수도 있겠죠 15:26 <jrandom> (syndie를 두 번 실행하지 않고도 로컬에서 여러 archive로 동작하기) 15:26 <+fox> <mk> 익명성에 도움이 될 수 있는 다른 이슈도 많아요 - 예를 들면 특정 archive들을 서로 배타적이라고 표시하는 것처럼요. 이런 모든 시나리오를 정의하고, 아주 사용하기 쉬운 방식으로 처리할 방법을 찾아야 해요 15:27 <tethrage> syndie는 익명성을 목표로 하지 않고, 보안만 목표로 하는 거 아닌가요 15:27 <tethrage> 그건 분명히 syndie가 동작하는 전송 계층이 처리해야 할 일 아닌가요? :/ 15:27 <jrandom> syndie는 익명성을 목표로 합니다 15:27 <tethrage> (제가 틀렸다면 바로잡아 주세요) 15:28 <jrandom> 전송 계층은 익명성의 일부분만 다룰 뿐이에요 - 나머지는 우리가 처리해야 합니다 15:28 <jrandom> s/small// 15:28 <tethrage> 정말요? :/ 15:28 <+fox> <mk> 네, 맞아요. syndie는 특히 정보 누출을 다룹니다 15:29 <jadeSerpent> ip address 익명성 대 identity 익명성 15:29 <tethrage> 그렇군요. 얼마 전에는 syndie가 암호화를 사용하는 보안 앱이지 엄밀히 익명적이진 않다고 말씀하신 줄 알았어요? 15:29 <tethrage> (어쨌든 i2p 등과 같은 방식은 아니다, 라고요) 15:29 <+fox> <mk> 정보 보안은 archive의 중복성으로 처리돼요 15:29 <jrandom> mk: archive를 표시한다는 게 무슨 뜻인지는 잘 모르겠지만, 그에 대해 syndie dev 포럼에 글 올려주시면 좋겠어요 :) 15:29 <jrandom> tethra: syndie는 익명이 필요 없는 용도로도 사용할 수 있어요 15:30 <jrandom> 하지만 익명이 필요한 용도로도 사용할 수 있어야 합니다 15:30 <jrandom> (그렇지 않으면, i2p 프로젝트의 일부로 구현할 이유가 없죠) 15:31 <tethrage> 네 15:31 <+void> jrandom: 공정하게 말하자면, syndie가 i2p를 활용해 익명성을 제공한다면 여전히 의미가 있겠죠 15:31 <+void> 하지만 그만하죠 15:31 <+void> c 15:31 <tethrage> 정보 누출과 미심쩍은 코드에 대한 보안 말고, 사람들의 익명성을 지키기 위해 syndie가 하는 게 또 뭐가 있죠? :/ 15:32 <tethrage> 분명히 지정하지 않으면 archive에 직접 접근하는 거 아닌가요 등등? 15:32 <+fox> <mk> tethrage, 온갖 종류의 정보 누출이요. 원하시면 잠시 후에 더 자세히 얘기할 수 있어요 15:33 <jrandom> tethra: 예를 들어, JavaScript가 활성화된 상태로 eepsite에 접근하는 경우요 15:33 <jadeSerpent> tethrage: 당신이 archive로 푸시한 게시물이 정말 당신에게서 기원했다는 보장은 없어요, 누군가가 당신의 archive로 푸시했을 수도 있죠 15:34 <tethrage> jrandom: 네, JS가 정보를 드러낸다든지 할 수 있죠. 하지만 어떤 형태로든 익명 네트워크를 쓰지 않는다면, 그건 익명성보다는 보안의 문제 아닌가요? 15:34 <tethrage> 다시 생각해보니, 말장난일 뿐인 것 같네요, 여기까지만 할게요 15:34 <tethrage> :/ 15:34 <jadeSerpent> 그 점에서는 공개 접근 가능한 archive를 직접 운영하는 게 오히려 익명성을 높인다고 생각해요 15:34 <+fox> <mk> jrandom, 그 글 올릴게요. 그리고 브라우저 디자인을 만져보고 있어요(새 섹션마다 새 탭 여는 걸 좋아하지 않아서요). 프로토타입을 만들어보고, 낙서 몇 개를 dev에 올려볼게요 15:34 <jrandom> '정보 누출에 대한 보안'이 익명성의 핵심이에요 - 당신의 identity에 대한 사실을 누가 알 수 있는지 통제하는 것 15:35 <jrandom> 오 멋져요 mk, 고마워요! 15:35 <jrandom> jadeSerpent: 물론이죠 15:35 <tethrage> 알겠어요 15:35 <tethrage> 이해했습니다 15:36 <jrandom> mk: syndie UI를 더 잘 보여줄 방법이 있다면 100% 찬성해요(탭 기반 컴포넌트에 묶인 코드는 극히 일부분이에요) 15:36 <jrandom> 어차피 아직 알파니까요 15:38 <+void> jrandom: 탭 인터페이스를 창 인터페이스로 바꾸는 게 어렵진 않겠죠? 15:38 <+fox> <mk> 네. 그리고 어떤 분들은 모든 걸 탭으로 하는 방식을 선호한다면, 그걸 쓰면 문제없죠 15:38 <+fox> <mk> (브라우저 탭과 나란히) 15:39 <jadeSerpent> 제발 MDI는 말아요, 탭과 MDI의 중간쯤, Eclipse의 perspectives 같은 걸 제안해요 15:39 <+void> MDI는 나쁘죠, 동의해요 15:40 <jadeSerpent> NetBeans에도 비슷한 게 있어요, 이름이 뭐였는지 잊었네요 15:40 <jadeSerpent> views나 workbench 뭐 그런 거요, 한동안 안 써서 15:41 <jrandom> .webp 스케치 환영합니다 :) 15:41 * jrandom은 모두 탭 방식으로 갔어요, 모두가 Firefox(/etc)를 좋아하니까요 15:42 <jadeSerpent> 아이콘을 끝내면 그 중 몇 가지를 해킹해볼지도 몰라요 15:42 <+fox> <mk> 2주 릴리스 주기는 좋아요. 그런 목표들을 명시적으로 보는 것도 좋지만, 좀 더 '부드러운' 목표들도 보고 싶어요 - 개발자 및 나중에는 사용자 문서, 다이어그램 등등 15:42 <jrandom> 끝내주네요 15:42 <jadeSerpent> 제 생각엔 지금은 탭으로 충분해요, 쓸 만하거든요 15:42 <jrandom> mk: http://syndie.i2p.net/roadmap.html ? 15:42 <jrandom> (다만 로드맵에 날짜는 없어요) 15:43 <+fox> <hottuna> 좋네요 :=) ... 방금 미결 작업에 대해 글 올렸어요 :P 15:44 <+fox> <mk> 네, 하지만 저는 더 작은 목표를 말한 거예요. "syndie.gui에서 클래스 간 일반 상호작용을 문서화", 또는 "차단(banning)에 관한 문서 작성" 같은 것들요. 15:44 <jrandom> 아, 좋은 지적이에요 15:45 <jrandom> 소/중/고수준 todo 항목들을 다시 취합하려고 생각하고 있었어요 15:45 * jrandom 그것도 todo 리스트에 추가 15:47 <jrandom> 좋아요, 2) Syndie 개발 상태에 대해 더 제기할 것 있나요? 15:48 <jrandom> (물론 syndie에 dev 포럼이 늘 있지만, IRC는 빠르게 주고받기에 유용하죠) 15:49 <jrandom> 그렇지 않다면, 3) 1월 버그 수확 대회 우승자로 넘어가죠! 15:50 <jrandom> Darn, voyde, mk, 그리고 Anonymous 축하합니다, 도와주신 모든 분들께도 감사드려요 15:51 * jrandom 원래는 상위 3명을 위한 대회였다는 걸 깨달았지만, 집계가 너무 비슷했어요 15:51 <jrandom> 이번 달에도 새 대회가 있어요, 규칙은 전과 동일합니다 15:51 <jadeSerpent> "Anonymous"가 한 사람이라는 건 어떻게 아시죠? ;) 15:51 <+fox> <mk> 총 225개(제 집계로) 버그 - 인상적이네요 15:51 <+void> :) 15:52 <+fox> <mk> jade, 키 때문이라고 봐요 :) 15:52 <jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) 15:53 <jrandom> 그 키를 다섯 명이 공유했을 수도 있죠 15:53 <jrandom> 하지만 그러면 $50USD를 나눠 가져야겠죠 ;) 15:53 <jrandom> (개인키로 서명한 메시지로 e-gold 계정을 지정해 저에게 보내는 사람이 우승이에요 ;) 15:53 <jadeSerpent> 한 명이 다른 사람들을 죽이지 않는다면요 15:54 <jadeSerpent> 하지만 그런 일은 루마니아에서만 일어나죠 15:54 <tethrage> 그리고 러시아 15:54 <jrandom> (그리고 영국, 호주, 그리고...) 15:55 <+fox> <mk> 50USD면 꽤 큰돈이죠... 15:55 <jadeSerpent> 러시아라면 전부 죽고, 집주인이 돈을 가져가서 보호비로 조직에 넘기겠죠 15:55 <tethrage> GBP로는 아니죠 ;p 15:55 <+fox> <mk> 그 돈이라면 저라도 죽일 거예요 15:55 <tethrage> mk, 어디 출신인지 물어봐도 답은 못 듣겠죠? 15:55 <tethrage> :/ 15:56 <+fox> <dw_g> 좋아요, 제가 받을게요 ;) 15:56 <+fox> <mk> 원래는 러시아 :D 지금은 캐나다예요 15:56 <jadeSerpent> 버그 225개라니 대단하네요, 그중 몇 개가 닫혔나요? 15:56 <tethrage> ice. 15:56 <tethrage> +n 15:57 <jrandom> jadeSerpent: 아마 75-80% 정도 처리되었다고 잡을게요 15:57 <jadeSerpent> 좋네요 15:58 <jrandom> (추가로 5-10%는 invalid/wontfix일 거예요) 15:58 <jrandom> 하지만 사실, 그건 상위 수준 todo 항목 중 하나예요 - 버그 트래킹에 제대로 된 관리 UI를 도입하는 것 15:58 * jadeSerpent는 trac을 추천합니다 15:58 <jrandom> (모든 글을 훑어보고 수작업으로 모두 세는 데 한참 걸렸어요) 15:58 <+fox> <mk> syndie 외부에요? 15:59 <jrandom> 흠, syndie-->track 내보내기 시스템이랑 함께요? 15:59 <jrandom> s/ck// 15:59 <+fox> <mk> syndie를 버그 트래커에 연결하는 건 괜찮은 프로젝트가 될 거예요 15:59 <jadeSerpent> 그렇죠 15:59 * jrandom 몇 개의 SQL 쿼리와 insert면 충분할 거라고 봅니다 16:00 <jrandom> 그래도 꽤 가치 있을 거예요, 최소한 read-only Trac 관점에서는요 16:00 <+void> 하지만 Trac에서 이뤄진 업데이트를 다시 syndie로 동기화하는 건 까다로울 거라 봐요 16:00 <jrandom> 전 주기 통합은 매우 어렵죠 16:00 <jrandom> 맞아요 16:00 <+fox> <mk> 어느 시점에는 'revision' 타입 시스템을 고려해볼 가치가 있을지도 몰라요 16:00 <jrandom> 하지만 Trac에서 조회하고 드릴다운하며 보고서를 생성할 수 있는 점 등은요 16:01 <+fox> <mk> 게시물이 이전 게시물을 대체하는 방식으로요 16:01 <jrandom> 아, 네 그런 훅은 있어요, 하지만 Overwrite* 헤더는 현재 존중되지 않아요 16:02 <jrandom> 그래도 그리 어렵진 않을 거예요. 같은 게시물의 이전 리비전으로 이동하는 UI 토글 하나랑, 새 게시물이 이전 게시물을 덮어쓸 권한이 있는지 확인하는 코드 몇 줄이면 되죠 16:03 <jadeSerpent> 버그 신고에 syndie 자체를 쓰고 싶은 마음은 이해하지만, 설계상 이슈 트래킹을 포함하지 않았고 그 작업에는 항상 최적이 아닐 거예요. 제 생각엔 진짜 이슈 트래커를 써야 해요 16:04 <+fox> <mk> 제출된 버그 수를 보니, jadeSerpent에게 동의해요 16:05 <jrandom> 하지만 반대로, syndie로 버그를 신고했기 때문에 발견된 버그가 얼마나 될까요? 16:05 * jrandom은 trac이나 다른 버그 트래킹 시스템에 전적으로 반대하는 건 아니에요 16:05 <jadeSerpent> 그런 종류의 버그는 어차피 발견될 거예요 16:05 <+void> 음, 심각도, 컴포넌트, 버전, 버그 닫기/열기/재열기는 syndie 태그로 할 수 있어요 16:05 <jrandom> 맞아요 16:06 <+void> (그리고 그중 대부분은 이미 그렇게 하고 있고요) 16:06 <jadeSerpent> 얼마 전 버그 리포트를 올리던 사람이 멈췄던 것처럼, 어떤 주제로 글을 쓰고 있었어도 멈췄을 거예요. 그게 버그 리포트였다는 건 중요하지 않았어요 16:06 <jrandom> 가명(그리고 진짜 인증된) 메시지로 실제 이슈 트래커에 공급할 수 있다면 훌륭하겠죠 16:06 * jrandom은 민감한 정보를 포함한 비공개 버그 리포트도 몇 건 받았는데, 이들은 syndie의 암호화로 보호돼요 16:07 <+fox> <mk> 음, 둘 다 유지하는 건 어때요? 16:08 <jadeSerpent> 다만 익명성이나 사소하지 않은 수준의 기밀성을 염두에 두고 설계된 이슈 트래커가 없다는 점에는 동의해요 16:09 <+fox> <mk> 그런 종류의 버그 트래커를 syndie가 갖추면 좋겠지만, 대부분의 버그 리포트를 제출할 때는 익명성이 그리 큰 문제는 아니에요 16:10 <jadeSerpent> 아마 Trac을 수정해서 syndie의 기능을 활용하게 할 수도 있겠죠 16:10 <+fox> <mk> jade, 어려울 거예요. 브라우저가 서명을 구현하지 않거든요 16:12 <jrandom> 흠. 우리가 가진 건 원래 다음을 기반으로 했어요: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003 16:12 <jrandom> 그리고 http://dev.i2p.net/~jrandom/bugsp1.txt 및 http://dev.i2p.net/~jrandom/bugsp2.txt 16:13 <jrandom> 이 이슈들을 추적하기 위해 지금보다 더 나은 무언가가 필요하다는 데 동의하고, 우리를 가장 잘 전진시킬 수 있는 어떤 것에도 열려 있어요 16:13 <jrandom> 하지만 가능하다면 최소한으로 유지하고 싶어요, 우리는 버그 트래커가 아니라 syndie를 만들고 있으니까요 :) 16:14 <jadeSerpent> 네 뭐, 지금은 그거 없이도 관리하는 것 같네요 ;) 16:14 <jrandom> 하지만 분명 몇몇은 틈새로 빠질 거고, 다른 사람들은 알려진 것 등을 찾고, 수정에 기여하기가 더 어려울 거예요 16:15 <+fox> <mk> 아마 syndie를 통해 구현할 필요조차 없을 거예요. 어느 정도는 유용하지만, 200개가 넘는 버그는 정말 많죠. 트래커를 하나 정해서 WWW와 i2p를 통해 접근 가능하게 해야 해요 16:16 <+fox> <mk> syndie의 버그 신고 화면 상단에 링크를 제공해서, 두 옵션을 모두 갖추는 거죠. syndie 안에 버그 트래커를 구현하는 건 지금 리소스를 써야 할 일이 아니에요 16:17 * jrandom은 버그 트래킹이 통합되는 걸 좋아하긴 해요(그래서 사람들이 버그 트래킹 계정을 만들거나, 가짜 이메일 주소를 쓰지 않아도 되니까요). 하지만 어떤 해결책을 쓸지 제안에는 열려 있어요 16:17 <+fox> <mk> 그건 유지하면서, 버그 트래커도 같이 갖춰야 한다고 봐요 16:18 <jadeSerpent> 단기적으로는 읽기 전용 접근만 있어도 좋겠어요 16:18 <jadeSerpent> 저는 버그에 더 초점을 맞춘 검색 인터페이스를 선호해요 16:18 <jrandom> 나쁘지 않겠네요, 웹 기반 것을 못 쓰거나 쓰고 싶지 않은 사람들을 위해, 큰 어려움 없이 일방향 syndie-->이슈 트래커 내보내기도 쓸 수 있을 거예요 16:19 <jrandom> s/of r/for/ 16:19 <+fox> <mk> 통합된 버그 제출은 좋은 기능이지만, 200개가 넘는 버그를 추적하는 데 syndie archive를 써서는 안 돼요 16:20 <jrandom> 그래도 우리의 검색 기능을 시험하기에는 아주 좋죠 :) [좋아요, 설득됐습니다] 16:20 <jrandom> 그럼, trac 한 표. 다른 표 있나요? 당연히 근거와 함께 syndie dev 포럼에 올려 주세요 16:21 <jadeSerpent> trac 두 표요, 제 표를 이미 세신 게 아니라면요 ;) 16:21 <jrandom> 네, 그걸 세고 있었죠 ;) 16:21 <+fox> <mk> 선택지가 뭐가 있죠? 트래커에 대해서는 아는 게 없어요 16:21 <jadeSerpent> 그건 당신 본인 표이길 바랐는데, 뭐 좋아요 16:22 <jadeSerpent> trac으로 일해봤는데, 서드파티 지원이 훌륭해요 16:22 <jadeSerpent> bugzilla는 별로라고 하겠어요 16:22 <jrandom> 그건 그렇고, 이슈 트래커에 꽤 익숙한 분이 있으면, syndie-->이슈 트래커 내보내기를 뚝딱 만드는 데 도움이 될 거예요 16:22 <jrandom> 맞아요, bugzilla는 괴물이죠 16:22 <jadeSerpent> jira도 좋아요, trac처럼요 16:23 <+void> trac은 많은 사람들에게 익숙할 거예요, too 16:23 <jrandom> 그래요, 좋은 분들이기도 해요(우리에게 i2p 라이선스를 줬지만, 아직 쓰진 않았죠) 16:23 <jadeSerpent> jira 라이선스가 있나요? 16:23 <jrandom> 네, jira와 fisheye요 16:24 <jadeSerpent> 좋네요, 한번 써보는 게 좋겠어요 16:24 <jadeSerpent> 참고로, Eclipse의 Mylar 플러그인은 bugzilla, trac, jira에 완전 통합돼요 16:24 <jadeSerpent> 인터페이스에 대한 칭찬이 많아요 16:25 <jrandom> 젠장 이 NetBeans/Eclipse 싸움 16:25 <bar> (버그가 생성될 때 자동으로 보고되나요? ;) 16:25 <tethrage> (하하) 16:26 <+fox> <mk> 하, 좋네요 16:26 <jadeSerpent> jrandom: NetBeans 지원은 제 기억이 맞다면 Mylar 로드맵에 있어요 16:26 <jrandom> 좋네요 16:26 <+fox> <modulus> Sun을 광적으로 지지하는 이들에게 그런 게 오죠 :-) 16:27 * jrandom이 modulus에게 javabeans를 던진다 16:27 <jadeSerpent> Mylar가 공식적으로 Eclipse 재단의 후원 아래 있긴 하지만요 16:27 <+fox> * mk는 trac의 라이브 사이트를 못 찾겠어요 16:27 <+fox> <modulus> http://trac.wordpress.org/ 16:27 <jrandom> mk: http://feedspace.i2p/ atm 16:28 <+void> http://trac.edgewall.com/ 16:29 * jrandom은 여러 다른 시스템을 평가하는 데 많은 시간을 쓰고 싶지 않으니, 누군가 특정 시스템을 강력히 밀고 싶다면 syndie dev 포럼에서 그렇게 해 주세요 16:29 <jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki 16:29 <+void> (^ 공식 메타-trac) 16:29 <+fox> <mk> 네, 저에겐 다 같아요 16:30 * jrandom은 * 3) 1월 버그 수확 대회 우승자!는 여기까지인 걸로 하고 4) ???로 넘어가겠습니다 16:30 <jrandom> 회의에서 더 할 얘기 있나요? 16:30 <+fox> <mk> '최고'는 과대평가됐죠. 이런 것들에 가장 경험 많은 사람이 아마 동전을 던지면 될 듯해요 16:32 * jrandom은 프로젝트 계획/릴리스 계획 시스템이나 소스 코드 브라우저를 찾는 게 아니에요(무료 위키도 나쁘진 않지만, 우리에겐 ugha.i2p도 있죠) 16:32 <jrandom> 그에 대해서 제가 신경 쓰는 유일한 기능은 이슈 추적이에요 16:37 <jrandom> 좋아요, 회의에 더 이상 없으면... 16:37 * jrandom 마무리합니다 16:37 * void가 jrandom에게 baffer를 건넵니다 16:37 * jrandom이 *baf*로 회의를 닫습니다