I2P 개발자 회의 - 2016년 4월 7일

20:00:05 <zzz> 0) 안녕하세요 20:00:05 <zzz> 1) 지난 회의에서 남은 안건들 http://zzz.i2p/topics/2093 20:00:05 <zzz> 2) kytv의 역할과 서비스 대체 http://zzz.i2p/topics/2098 20:00:05 <zzz> 3) 0.9.26 계획 업데이트 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:00:05 <zzz> 4) HOPE 계획 http://zzz.i2p/topics/1968 20:00:05 <zzz> 5) 월례 회의와 프로젝트 관리 3개월 회고 20:00:10 <zzz> 0) 안녕하세요 20:00:12 <zzz> 안녕 20:00:38 <zzz> 1) 지난 회의에서 남은 안건들 http://zzz.i2p/topics/2093 20:00:55 <orignal_> hi 20:01:00 <zzz> - Reseed 캠페인 준비, 1월 말까지: 20:01:00 <zzz> ** Sadie가 backup에게 연락하여 논의 - OPEN, 새 날짜 4월 5일 20:01:11 <zzz> sadie, 진행 상황은? 20:02:10 <zzz> - 네트워크 강화 - 홈 페이지 및 추가 페이지 20:02:10 <zzz> ** str4d, gravy, cacapo: 사용 사례 추가, 우리가 가장 잘하는 것, 더 많은 "passion"과 "fat", Bote 추가/강조, 1월 말까지 - OPEN, str4d가 3월 6일까지 웹사이트에 사용 사례 추가, passion 등 추가 변경은 4월 5일까지 20:02:15 <zzz> str4d, 진행 상황은? 20:03:06 <zzz> - I2P "Story" / 역사 / 왜 하는가 추가 20:03:06 <zzz> ** comraden이 2월 말까지 편집/다듬기/개선/게시 - OPEN, 새 날짜 4월 1일, 초안은 3월 중순까지 zzz에게 회신 20:03:11 <zzz> comradenosebleed, 진행 상황은? 20:03:34 <str4d> 안녕하세요 20:04:40 <zzz> 티켓 관리 - 현재 임시(ad hoc) 20:04:40 <zzz> ** Sadie가 검토하고, 권고안을 제시하거나 가능하면 직접 관리 시작 (기한은?) - OPEN, str4d와 sadie가 4월 5일까지(?) 회의 일정을 잡거나 보고서 제출 20:04:50 <zzz> sadie, str4d: 진행 상황은? 20:05:49 <hottuna> hi 20:05:59 <zzz> str4d OPEN - Android 0.9.24 3월 3일 릴리스, TODO 목록 3월 6일까지 취합, 로드맵 초안 3월 6일까지, 3월 5-6일 검토 20:06:05 <zzz> str4d, 진행 상황은? 20:06:33 <str4d> 논의했습니다 20:06:41 <str4d> (죄송, 회의 두 개를 동시에 하고 있어요) 20:06:54 <zzz> str4d와 zzz가 2월 12일까지 VRP 티켓 검토; 3월 5-6일 로드맵 회의 중에 일부 결정을 내릴 예정 (zzz는 2월 8일 완료, str4d는 3월 6일까지) 20:06:56 <str4d> 티켓 관련 20:06:57 <zzz> str4d, 진행 상황은? 20:07:29 <zzz> sadie와 anonimal이 Monero 0mq 기반 CoC 수정안을 4월 5일 회의에서 가져오기 20:07:36 <zzz> sadie, anonimal: 진행 상황은? 20:08:25 <str4d> 난이도 분류가 필요한 티켓을 위해 "new" 상태를 두기로 예전에 결정했고, 지금도 그게 맞다고 봅니다 20:09:00 <str4d> 우리 몇 명이 정기적으로 모여 이 티켓들을 살펴보는 시간도 정하는 게 좋다고 생각합니다 20:09:09 <str4d> Android 관련 20:09:59 <str4d> 빌드 스크립트가 막혀서 아직 진행되지 않았습니다 20:10:17 <eche|on> uhh 20:10:54 <str4d> VRP 티켓: 작업하려던 때 아파서 아직 진행하지 못했습니다 20:11:00 <zzz> 현재의 프로젝트 관리 방식이 효과가 없다는 건 분명합니다. 아무것도 일어나지 않고 있어요. 넘어가죠. 그리고 5) 항목을 안건에 넣은 이유는 월례 회의를 계속할지 결정하기 위해서입니다 20:11:10 <zzz> 거의 모든 항목이 3과 1/3개월째입니다 20:11:19 <str4d> zzz의 목록에는 없지만, 제가 완료한 것은 스펙 마이그레이션을 끝냈고 제안서 마이그레이션도 상당히 진행 중이라는 점입니다 20:11:37 <zzz> 스펙/제안서 소식은 훌륭하네요, 잘하셨습니다 20:12:09 <str4d> 그래서 "아무것도 없다"는 건 아니라고 말하고 싶습니다. 다만 현재 PM 스타일에는 반영되지 않은 우선순위 이동이 있었던 거죠 20:12:17 <str4d> 그러니 네, 개선이 필요합니다 20:12:20 <zzz> 좋아요. 좋은 관점이에요 20:12:25 <zzz> 1) 관련해 더 있나요? 20:13:04 <str4d> 다른 분들을 위해, 제안 관련 내용은 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals 에 있습니다 - 검토하고 의견 부탁드립니다 :) 20:13:26 <zzz> 2) kytv의 역할과 서비스 대체 http://zzz.i2p/topics/2098 20:13:34 <zzz> 그가 하던 일이 약 20가지 목록으로 있습니다 20:13:44 <str4d> 제 쪽은 더 없습니다 20:13:47 <str4d> (I2P Android 작업은 했지만, 릴리스까지는 못 갔습니다) 20:13:55 <zzz> 저는 최우선이라고 본 것들에 집중했습니다 - launchpad와 debian 20:14:14 <zzz> 다른 몇몇은 다른 것들을 조사 중이고, .25에서는 콘솔 홈 페이지 링크 몇 개를 바꿨습니다 20:14:33 <zzz> 제게 다음으로 중요한 건 tails 메인테이너입니다 20:15:06 <zzz> 여기 tails와 debian 패키징을 모두 아는 분이 계신가요? 도움 가능하신가요? 아니면 제가 최대한 빨리 트위터에 공지를 올리겠습니다 20:15:24 <zzz> 우리는 두 달 후 다음 릴리스에서 tails에서 제외될 수도 있습니다 20:15:32 <zzz> 아마 2.4일 겁니다 20:15:50 <zzz> 이건 제 능력 범위를 넘습니다. 저는 안 할 겁니다. 20:16:02 <str4d> 으으 20:16:19 <str4d> Tails가 최소한으로 요구하는 건 무엇인가요 20:16:19 <str4d> ? 20:16:20 <zzz> 제 debian 패키징을 받아 tails에 조정/삽입하고, 테스트 테스트 테스트, 그리고 기존 tails I2P 티켓 여러 건 처리하는 겁니다 20:16:49 <zzz> kytv가 작성한 큰 문서가 있어요, 아마 zzz.i2p의 kytv 스레드에서 링크되어 있습니다 20:17:04 <zzz> 기본적으로 tails에 주는 입력은 deb 패키지입니다 20:17:19 <zzz> 하지만 그들이 불만 사항 백로그를 갖고 있는 것 같습니다 20:17:25 <eche|on> 트위터에 공지 20:17:33 <str4d> 트위터 +1 20:17:35 <zzz> kytv 대체 관련해서 보고할 게 또 있나요? 20:18:07 <str4d> 1~2주 전 IRC에서 언급한 이후로 Buildbot CI 서버는 더 진전이 없습니다 20:18:23 <str4d> 이번 주말에 더 작업하겠습니다 20:18:42 <zzz> 좋아요. 목록에 할 일이 많으니, 각자 중요한 걸 하나씩 맡아봅시다. 20:19:02 <zzz> 2) 마지막 콜 20:19:46 <str4d> 아무도 안 하면, 제가 IRC 봇/릴레이를 맡을 수도 있습니다. 당장은 가능성 낮습니다. 20:20:34 <zzz> deb 빌드는 상태가 괜찮은 편이지만 jessie용 arm 같은 건 제가 오늘 고쳤을 수도 있고 아닐 수도 있습니다 20:21:19 <zzz> 3) 0.9.26 계획 업데이트 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:21:33 <zzz> 좋아요, 3a) 일정 그리고 3b) GMP 6로 가겠습니다 20:21:38 <zzz> 3a) 일정 20:22:03 <zzz> 로드맵에는 '5월'이라고 되어 있고, 지난 3월 22일 릴리스에서 6-7주면 5월 초중순입니다 20:22:36 <zzz> 한 달 전 로드맵 회의에서, 주소록 구독 프로토콜을 포함한 야심찬 계획을 세웠습니다 20:23:16 <zzz> 그런데 바로 다음 날 kytv의 것들이 전부 내려가고, 돌아올 가능성이 낮아지면서 그 계획은 무너졌습니다 20:23:36 <zzz> 그래서 26 관련해서는 아직 아무것도 시작하지 못했습니다. 지난 2-3주는 debian/launchpad 작업으로 꽉 찼어요 20:24:01 <str4d> 지금부터 7주면 5월 말입니다. 가능하다고 보시나요? 20:24:15 <str4d> (debian 쪽이 대체로 정리된 만큼) 20:24:19 <zzz> 그러면 26이 아마 6월로 밀릴 겁니다. tails 2.4 마감도 한참 지나게 되고요 20:24:37 <str4d> 으으 20:24:37 <zzz> 5월 말도 가능하긴 한데, 날이 갈수록 가능성이 줄어들고 있습니다 20:24:42 <str4d> tails 마감은 언제죠? 20:25:11 <zzz> 정확히는 모릅니다. 25를 그들 스스로 가져가 달라고 이미 재요청했어요 (한 번 거절당했습니다) 20:25:23 <eche|on> tails는 현재 판단 중이니 6월도 괜찮다고 봅니다 20:25:45 <zzz> 그들은 tails에서 I2P 사용 현황을 볼 수 없고 요구도 못 듣습니다. 그래서 그들이 보기엔 번거롭기만 한 거죠 20:26:18 <eche|on> 맞아요 20:26:33 <zzz> 보통 주소록 구독 프로토콜 같은 큰 기능은, 이전 릴리스 일주일 전에는 끝내서 prop할 준비가 되어 있어야 합니다 20:26:54 <zzz> 그러니 3주가 이미 밀렸고, 여기에 개발 시간 최소 몇 주가 더 필요하니 총 5주가 뒤처진 셈입니다 20:27:39 <zzz> 이게 현재 상태입니다. 아직 공식 로드맵에 내보내진 않았지만 곧 해야 합니다 20:27:49 <zzz> 3a) 일정 관련해서 더 있나요? 20:27:58 <str4d> 실제 0.9.27 릴리스에 넣기로 했던 건 뭐였죠? 20:28:16 <zzz> 위의 로드맵 링크를 보세요 20:28:31 <zzz> 초기 ntcp2/dh/pt 20:29:18 <str4d> 거기 적힌 순서대로 진행해야 한다고 여전히 생각합니다. 그래서 우리가 할 수 있는 건 주소 구독 프로토콜을 0.9.27로 미루는 겁니다 20:29:27 <str4d> 그러면 5월은 그 작업 시간으로 드릴 수 있습니다 20:29:47 <zzz> 하지만 아직 .26이 없습니다. 아무도 아무것도 안 했어요. deb 변경 말고는 들어간 게 없습니다 20:29:50 <str4d> 그러면 .26은 CRL과 일반적인 정리 정도로 20:30:08 <zzz> 누군가 (저 포함) 뭔가를 하기 전까진, 릴리스할 게 없습니다 20:30:27 <zzz> 지켜봅시다. 저도 세금 신고 때문에 며칠은 쉬어야 해요 :) 20:30:37 <zzz> 3a) 일정 관련해 더 있나요? 20:30:55 <eche|on> 계획한 일정에 너무 매달리지 맙시다 20:30:56 <str4d> sadie와 논의하면서 나온 초기 UI 조정 몇 가지가 있는데 적용할 수 있습니다 20:31:20 <zzz> 3b) GMP 6 20:31:25 <str4d> (제가 계획한 대규모 재설계는 아니고, 일반적인 다듬기입니다) 20:31:50 <zzz> 약 15개월 작업 끝에, tuna와 저는 26을 위해 gmp6 브랜치를 trunk로 prop할 준비가 거의 되었습니다 20:32:05 <zzz> tuna는 지난 6개월 동안 만든 바이너리가 약 100개 있고, 체크인 대기 중입니다 20:32:25 <zzz> 다양한 방법으로 빌드했습니다 - VM, 네이티브, Microsoft, 빌린 시스템 등 20:32:53 <zzz> 전통적으로는 체크인하는 각 바이너리에 대해 빌드 환경(컴파일러 리비전, 시스템 OS 상세 등)에 관한 자세한 노트를 함께 체크인해 왔습니다 20:33:13 <zzz> 안타깝게도 tuna는 어떤 빌드에 대해서도 기록을 남기지 않았습니다. 20:34:06 <zzz> 그래서 질문은 이렇습니다. 처음부터 다시 시작할까요 (6개월이 들 수 있음), 아니면 제가 linux 바이너리만 빌드하고 나머지는 무시할까요, 아니면 사실 그런 노트가 꼭 필요하진 않으니 tuna가 한 모든 걸 그대로 받아 진행할까요? 20:34:08 <eche|on> 다시 할 수 있는 가능성은? 20:34:47 <zzz> tuna 말로는 불가능하답니다. 누구든 linux 32/64 바이너리는 빌드할 수 있지만, 나머지는 문제가 많습니다 20:35:00 <eche|on> 좋은 질문이네요. 이 케이스에선: 재빌드하거나 받아들이거나, 중간은 없습니다 20:35:25 <eche|on> mac, win, arm용 gmp가 필요합니다 20:35:29 <zzz> 마지막에 tuna가 한 말은 받아들이든 말든, 그는 끝났다는 겁니다 20:35:54 <zzz> 빌드가 빠르더라도, 테스트는 느립니다 20:36:25 <str4d> 테스트 프로세스가 어딘가 문서화되어 있나요? 20:36:54 <zzz> http://zzz.i2p/topics/1960 의 마지막 페이지로 가면 그가 가진 모든 빌드 노트를 제출해 놓았습니다 20:36:56 <eche|on> (참고로, 우리는 이미 노트 없이 다른 것들도 받아들인 적이 있습니다) 20:37:07 <str4d> 이건 정확히 CI 서버에 넣어야 할 것처럼 들리네요 20:37:38 <zzz> 빌드 방법에 대한 readme는 업데이트했습니다. 테스트 방법에 대한 정보도 스레드에 일부 있고, 저도 제 나름의 방법을 개발했습니다 20:38:07 <zzz> 지난 6개월간 그가 바이너리 컬렉션을 13번 릴리스했다는 걸 기억하세요 20:38:36 <zzz> hottuna, 덧붙일 게 있나요? 20:38:37 <str4d> 누군가 테스트 방법론을 정리해 주면, Buildbot에서 빌드 타입으로 만들 수 있습니다 20:38:58 <str4d> 그러면 그걸 붙일 머신만 찾으면 됩니다 20:39:08 <hottuna> 잠시만요 20:39:24 <str4d> 어딘가에 Mac 한 대를 빌드슬레이브로 돌릴 수 있도록 투자하는 걸 생각하고 있습니다 20:39:44 <hottuna> eche|on: 재빌드 관련: 불가능하진 않지만, 지금 제게는 일이 너무 많습니다. 정말로요. 20:40:02 <str4d> 너무 비싼 건 말고, trio를 완성할 수 있을 정도면 됩니다 (eche와 VM 정리되면 이미 linux와 windows 빌드슬레이브는 있게 됩니다) 20:40:10 <eche|on> hottuna: 재빌드 방법이 있나요? 20:40:27 <zzz> 100개 파일 빌드가 내일 당장 된다고 해도, 테스트엔 3개월이 걸릴 겁니다 20:40:39 <hottuna> 필요한 건 모두 들어 있어야 하는 readme 문서가 있습니다. 20:40:48 <str4d> 최소한, 우리는 hottuna의 다양한 스크립트 개선의 이익을 얻었습니다 20:41:10 <str4d> 그런데 지금 재빌드한다면, 6.1로 바로 건너뛸까요 20:41:11 <zzz> 게다가 cpuid 코드 자체에 대규모 변경이 있습니다 20:41:23 <hottuna> str4d: 스크립트가 완벽하진 않지만, 그래도 더 좋아졌습니다. 20:41:23 <zzz> 맞아요, 6.1일 수도 20:41:25 <str4d> 네 20:41:30 <hottuna> str4d: 재빌드한다면 6.1로 가야 합니다 20:41:44 <eche|on> 새 코드가 잘 동작하나요? 20:41:57 <hottuna> eche|on: 우리가 아는 한 버그는 없습니다(하!). 20:42:07 <zzz> debian 빌드에서는 동적 링크하니, 설치되어 있다면 어차피 6.1을 쓰게 됩니다 (그리고 생각나서 말인데, gmp 6 동적 라이브러리는 테스트하지 않았습니다) 20:42:10 <str4d> 6.1을 하려면 스크립트를 얼마나 바꿔야 할지 확신은 없지만, 기본적으로 드롭인으로 동작하길 바랍니다 20:42:14 <eche|on> 테스트가 괜찮았다면 포함합시다. 그리고 6.1로는 사이드 채널에서 재빌드하고, 정보는 나중에 반영하죠 20:42:38 <eche|on> 제 생각엔, 이미 꽤 잘 테스트했습니다 20:42:51 <hottuna> eche|on: 까다로운 부분은 실제 스크립트를 돌리는 게 아니라, 머신을 확보하고 환경을 설정하고 테스트하는 거였습니다. 그게 까다롭고 느렸죠 20:43:03 <eche|on> 네 20:43:13 <str4d> hottuna, 그걸 CI에 녹이고 싶습니다 20:43:15 <zzz> 원래 질문으로 돌아가죠. 6개월의 작업(사실 2015년 초부터였음)을 버릴까요, 아니면 바이너리 출처에 대한 구체적 노트가 없어도 지금 갖고 있는 바이너리를 받아들일 수 있을까요 20:43:25 <str4d> 몇 대의 서로 다른 머신을 사용했다고 보시나요? 20:43:37 <zzz> 일단 CI 얘기는 잠시 접고, 문제가 있는지 없는지부터 정합시다 20:43:52 <hottuna> str4d: 대체로 드롭인일 겁니다. 타깃이 한두 개 추가될 수 있어요. gmp가 지원하는 최신 아키텍처를 지원하지 않을 이유가 없죠 20:44:13 <str4d> zzz, 저는 6.1로의 마이그레이션을 하기로 전제하고 바이너리를 받아들이고 싶습니다 20:44:24 <hottuna> str4d: ~6개의 구분되는 환경 20:44:29 <zzz> 6.1은 올해 말 로드맵에 있습니다 20:44:39 <zzz> 현재 바이너리는 6.0입니다 20:44:41 <str4d> 바이너리를 받아들이면 파급 효과가 뭐가 있죠? 20:44:41 <hottuna> str4d: 교차 컴파일이면 꼭 여러 머신이 필요하진 않습니다 20:44:51 <str4d> 1) mtn에 들어간다 20:45:01 <zzz> 또한 특정 하드웨어에서 큰 속도 향상이 있고, constant time도 제공합니다 20:45:17 <str4d> 2) 관련 업데이트 파일과 설치 파일에 번들된다 20:45:21 <zzz> '파급 효과' = 안 좋은 일인가요? 20:45:28 <str4d> 2a) 업데이트 파일 크기가 많이 커진다 20:45:44 <str4d> 3) 특정 시스템에서 깨지면 어떻게 되나? 20:46:03 <str4d> 1)은 어차피 계획했습니다 20:46:26 <zzz> .26에 즉시 prop할 경우에만 바이너리를 체크인합니다. 20:46:28 <str4d> 2)도 마찬가지인데, 6.0 바이너리는 6.1로 대체될 테니 큰 문제는 아닙니다 20:46:37 <str4d> 제가 걱정하는 건 3)입니다 20:46:43 <zzz> 릴리스 대상 바이너리만 체크인됩니다 20:47:00 <str4d> 3a) 실패 상태를 확인하는 기존 코드가 있나요? 20:47:04 <zzz> 3)은 모든 변경에 대한 일반적인 리스크입니다 20:47:19 <zzz> gmp의 실패는 일반적으로 JVM 크래시입니다 20:47:26 <str4d> 3b) 예전의 동작하는 libjbigi로 폴백할 방법이 있나요? 20:47:44 <str4d> (자동이든 수동이든) 20:48:00 <str4d> 예를 들어, 예전 libjbigi의 이름을 바꿔서 문제가 생기면 사용자에게 "이 파일 이름을 바꾸세요"라고 안내할 수 있을까요 20:48:22 <zzz> str4d, 우리가 애초에 jbigi를 변경해야 하느냐를 따지는 건가요? 이건 gmp를 바꾸는 것 전반에 대한 일반적인 영향입니다 20:49:14 <str4d> zzz, 당신의 우려는 이 바이너리의 정확한 출처를 모르기 때문입니다. 그렇다면 문제가 생기면 원인을 추적하기가 훨씬 어려워진다는 게 걱정이겠죠. 20:49:27 <str4d> 그래서 저는 완화 전략을 생각 중입니다 20:50:00 <zzz> 26 업데이트에 jbigi.jar를 포함하지 않을 수 있습니다. 그러면 신규 설치에만 들어가죠. 더 느린 롤아웃이 됩니다. 20:50:25 <zzz> 신규 설치 + launchpad/deb 20:50:57 <zzz> 일반적인 해결책은 libjbigi.so와 jbigi.jar를 제거하는 겁니다. 그러면 그 없이 동작합니다 20:51:01 <str4d> 그게 어차피 좋은 생각일 수도 있습니다 20:51:30 <str4d> 신규 설치에 먼저 배포하고, 문제가 없다는 피드백을 받으면 다음 릴리스에서 업데이트에 포함시키죠. 20:51:43 <zzz> tuna의 요지는 어차피 재현 가능하지 않다는 겁니다. 전부 빌린 시스템과 오래된 VM들이거든요 20:52:23 <zzz> eche|on, hottuna가 win 빌드에 사용한 박스의 시스템과 msvc 정보가 있나요? 20:53:10 <zzz> tuna는 연구를 자처하진 않았는데, sadie의 노트북도 빌리지 않았나요? 아니면 그 사이 업그레이드가 있었을 수 있으니 다 소용없나요? 20:53:24 <eche|on> 그는 내 kvm 호스트의 win 10 머신에 접근권이 있었어요. 로그인해서 확인할 수 있습니다 20:53:33 <str4d> 음, 그래서 6.1 빌드는 추적 가능한 빌드서버(Buildbot)에서 하자고 하는 겁니다. 20:53:57 <hottuna> zzz: OSX 머신은 친구들 거 두 대를 빌렸습니다 20:53:58 <eche|on> VM은 전혀 변경하지 않았습니다 20:54:33 <zzz> 우리가 돈을 내고 공짜로 줄 Mac을 가져가겠다는 사람도 없어요. 아무도 'mac 담당'이 되길 원치 않거든요 20:54:51 <zzz> 그러니 문제는 돈이 아니라 시간과 사람입니다 20:55:17 <hottuna> zzz: 저는 들고 다녀야 하는 장비를 원치 않을 뿐입니다. 20:56:01 <zzz> 여기 hottuna의 완전한 빌드 노트가 있습니다: 20:56:03 <zzz> Build notes jbigi: 20:56:03 <zzz> ------------------ 20:56:03 <zzz> Windows: Cross-compile, linux hosts. Compiler: GCC 20:56:03 <zzz> Linux: Native build. Compiler: GCC 20:56:03 <zzz> FreeBSD: Native build, VM. Compiler: GCC 20:56:03 <zzz> OSX: Native build. Compiler: GCC 20:56:03 <zzz> Build notes jcpuid: 20:56:03 <zzz> ------------------- 20:56:03 <zzz> Windows: Native build. Compiler: MSVC 20:56:03 <zzz> Linux: Native build. Compiler: GCC 20:56:03 <zzz> FreeBSD: Native build. Compiler: GCC 20:56:03 <zzz> OSX: Native build. Compiler: GCC 20:56:17 <zzz> 이 정도로 충분할까요, 아니면 처음부터 다시 시작할까요? 20:57:14 <str4d> 어차피 올해 말까지 6.1로 마이그레이션할 거고, 이 바이너리도 합리적인 테스트를 거쳤으니, 저는 충분하다고 봅니다. 20:57:41 <zzz> 이의 있습니까? 20:57:45 <eche|on> 최소한 시작점은 되지만, "Tor의 재현 가능한 빌드" 관점에선 아무것도 아닙니다. 우리가 원하는 표준은 어떤 수준이죠? 20:58:03 <hottuna> 아니요 20:58:34 <eche|on> 새 설치에 "임시(temp)" 플래그로 포함하고 싶습니다. 힘든 작업이란 건 압니다. 20:59:14 <zzz> 기본적으로 현재 테스트는 0으로 떨어졌습니다. 더 많은 테스트를 받는 유일한 방법은 trunk와 릴리스에 넣는 것입니다. 20:59:17 <susbarbatus> 끼어들어 죄송합니다; 저는 mac이 여러 대 있고, mac이나 bsd 담당이 되는 것도 문제 없습니다. 회의 후에 무엇이 필요한지 알려주시면, 제가 충분히 지식이 있거나 배워서 기여할 수 있는지 판단해 보겠습니다. 20:59:29 <zzz> 훌륭합니다, susbarbatus 20:59:44 <str4d> susbarbatus, 정말 환상적이네요 20:59:47 <zzz> 그럼 hottuna에게 체크인해 달라고 하죠 20:59:53 <eche|on> zzz: 맞아요, 우리는 릴리스가 100% 안전하고 완전하다고 한 적은 없죠^^ 21:00:05 <zzz> hottuna, 브랜치는 i2p.i2p.str4d.gmp6 입니다 (i2p.i2p.zzz.gmp6 아님) 21:00:17 <hottuna> 알겠습니다 21:00:38 <zzz> hottuna, 제거해야 할 것들은 mtn drop 하는 거 잊지 마세요. 완료 후 디렉토리는 당신의 v13 zip과 정확히 일치해야 합니다 21:00:50 <zzz> 3b) 관련해 더 있나요? 21:00:55 <hottuna> 우리가 빌드하지 않은 플랫폼용 기존 jcpuid/바이너리는 제거할까요? 21:01:09 <str4d> susbarbatus, 제가 설정하고 싶은 건 빌드서버입니다. 항상 켜둘 수 있는 Mac을 제공하시고, 문제가 생겼을 때 질문/지원에 응답해 주실 수 있다면요. 일반적으로는 자동 제어되니 참여가 많이 필요하지는 않을 겁니다 :) 21:01:28 <zzz> 제안은 v13이 릴리스할 것과 "정확히" 같다는 것이었습니다. 그 이상도 이하도 아니고요. 21:01:38 <zzz> 원하시면 회의 후에 다시 검토할 수 있습니다 21:01:38 <str4d> 항상 켜두지 못하더라도, 빌드서버 설정에서 쉽게 시작할 수 있으면 됩니다 21:01:51 <hottuna> zzz: 좋습니다 21:01:54 <str4d> (buildmaster가 항상 온라인이 아닌 buildserver도 처리합니다) 21:02:12 <zzz> 빌드서버 얘기는 보류하고 4)로 넘어갑시다 21:02:22 <zzz> 4) HOPE 계획 http://zzz.i2p/topics/1968 21:02:23 <susbarbatus> str4d: 문제 없습니다. 제 ~2012 mac mini를 연결해 둘 수 있어요. 느리긴 하지만 다른 용도는 없습니다. 21:02:24 <str4d> ACK 21:02:33 <str4d> ^5 susbarbatus :) 21:02:52 <eche|on> hope - 쓸 수 있는 티켓이 하나 있습니다 21:02:57 <zzz> 이번 주 Lance와 만났습니다. 여전히 제안은 그는 HOPE 전날이나 다음 날 하루 종일 사용할 수 있는 작은 회의실을 제공한다는 것입니다 21:03:04 <zzz> 즉, 7월 21일 또는 25일 21:03:22 <zzz> 비행기표를 살 수 있도록 곧 날짜와 확약이 필요하다고 강조했습니다 21:03:46 <zzz> 일반에 공개되지는 않습니다. 초대 전용, 5-6명, 로드맵 회의 등을 위한 소규모 모임입니다 21:03:51 <str4d> 현 단계에서 참석을 확약하긴 어렵습니다. 그때쯤 미국에 있을 가능성이 조금은 있지만요 21:04:00 <zzz> 그리고 서로 무엇을 하는지 발표하는 시간도 갖습니다 21:04:30 <zzz> 현재 확정은 저와 sadie이고, comradenosebleed와 lazygravy는 미정입니다. 또 누가 있나요? 21:04:49 <zzz> 여행 일정을 확정해야 하는 마감 날짜는 언제인가요? 21:05:33 <zzz> 저와 sadie만이라면 전체를 취소할 수도 있겠지만, 좀 더 봅시다 21:05:39 <zzz> 누구요? 21:06:04 <zzz> hottuna 올 건가요? 21:06:07 <str4d> (모든 건 제 학위 논문 방어 일정에 달렸습니다. 아직 언제인지 모릅니다) 21:06:09 <str4d> (비자 관련 이슈도 있고요) 21:06:17 <str4d> 논문 방어가 그 전에 끝나면, 참석하고 싶습니다(그냥 경유라도) 21:06:17 <eche|on> 관심은 있지만, 비행기와 호텔 비용을 낼 수는 없습니다. 특히 우리가 나중에 can에서 만난다면요 21:06:17 <str4d> 그러니 한 달 후쯤 다시 물어보세요 21:06:45 <zzz> 알겠습니다, Lance를 계속 압박해서 확정 짓고, 사람들이 모이길 기대하겠습니다 21:06:50 <zzz> 4) 마지막 콜 21:07:00 <hottuna> zzz: 시간적으로 매우 애매합니다. 7월 16일 EU에 결혼식이 있어야 하거든요. 21:07:15 <hottuna> 지금은 확약할 엄두가 안 납니다,. 21:07:20 <zzz> 좋아요, 돌아오는 길에 뉴욕을 경유하세요 :) 21:07:26 <hottuna> (지금 확정해야 한다면 더더욱요) 21:07:33 <hottuna> 흠.. 21:07:44 <hottuna> 나쁘지 않은 아이디어네요 21:07:47 <zzz> 5) 월례 회의와 프로젝트 관리 3개월 회고 21:07:59 <str4d> 그러니 저를 밋업은 희망, HOPE는 가능성 낮음으로 표시해 주세요 (티켓이 필요하다고 확약할 수는 없지만, 그때 거기 있으면 남는 티켓을 쓸게요) 21:08:26 <zzz> 제 관점에선 이게 전혀 작동하지 않습니다. 액션 아이템이 거의 완료되지 않았어요. 고칠 수 있을까요, 아니면 월례 회의를 그만둘까요? 21:08:40 <str4d> 고칠 수 있다고 생각합니다 21:08:42 <zzz> 아무도 아무것도 안 하면, 관리할 것도 없습니다. 완전히 그런 건 아니지만 거의 그래요 21:09:11 <str4d> 최소한 월례 회의는 유용하다고 생각합니다 21:09:30 <zzz> 목표는 프로젝트 관리를 sadie로 전환하는 것도 있었는데, 그녀는 회의에도 나오지 않으니 그것도 순조롭지 않네요 21:09:32 <hottuna> 동의합니다 21:09:44 <str4d> 그녀는 한 시간 일찍인 줄 알았어요 21:09:49 <str4d> 지금은 다른 회의 중입니다 21:10:19 <str4d> (한 시간 일찍 왔는데 여기선 아무도 얘기하고 있지 않았죠) 21:10:41 <zzz> 그렇죠, 회의 운영 안 해도 되면 다들 회의를 좋아하죠. 그런데 저는 매달 3개월 전에 누가 약속한 게 되었는지 묻는 바보처럼 보입니다. 지칩니다. 21:10:49 <str4d> 이걸 sadie와 논의했고, 우리가 함께 하는 항목들을 관리하기 위해 주간 회의를 잡았습니다 21:11:19 <str4d> zzz, 그럼 회의의 초점을 "이거 했나요"로 두지 마세요 21:11:36 <zzz> 진척이 너무 없고 kytv가 사라진 걸 보면 상황이 매우 심각하다고까지 보는 게 지나친 걸 수도 있지만, 저는 우리가 곤경에 처했다고 생각합니다 21:11:40 <hottuna> zzz: sadie로의 전환은 언제로 예정인가요? 21:11:40 <str4d> 월례 회의는 우선순위 재평가와 재조직에 더 초점을 맞추는 게 좋다고 봅니다 21:11:58 <zzz> 그럼 사람들이 약속한 걸 하도록 어떻게 트랙을 유지하죠? 21:12:13 <str4d> "이거 했나요"는 a) 더 많은 개인 책임감과 b) 더 많은 1:1 피드백이 필요합니다 21:12:30 <hottuna> zzz: 결코 좋다고 할 순 없지만, "큰 곤경"은 과장일 수도 있습니다. 21:13:02 <str4d> 제 경우엔, 제 작업을 트랙하기 위해 sadie와 주간 회의를 만들었고, 제 I2P TODO 리스트 접근 권한도 줘서 우선순위 설정을 도와달라고 했습니다 21:13:07 <susbarbatus> str4d: 요지는, 모두가 약속/커밋을 지켰다면 zzz가 "이거 했나요"를 묻지 않아도 됐다는 거죠 ;). 21:13:12 <str4d> (우리는 아직 회의를 한 번만 했으니, 어떻게 되는지 지켜봐야 합니다) 21:13:17 <str4d> susbarbatus, 맞아요 21:13:50 <str4d> 우리는 사람들이 정규 업무 외에 재미/봉사로 이 일을 한다는 사실을 처리할 만큼 유연해야 합니다 21:14:13 <zzz> 맞아요. 제 시스템은 현재, 무언가를 완료하면 회의용 zzz.i2p 스레드에 보고하는 겁니다. 그래야 여기서 회의 시간을 낭비하지 않거든요 21:14:15 <str4d> 하지만 누군가 일을 못 하고 있다면 도움이 되지 않는다는 것도 강조해야 합니다 21:14:28 <zzz> 사람들이 완료하지도, 보고하지도 않으면 여기서 시간을 낭비할 수밖에 없습니다 21:14:42 <str4d> 그리고 무기한 막는 것보다는 다른 사람에게 넘기는 게 낫습니다 21:14:54 <str4d> (I2P Android에서 현재 무기한 막고 있는 제가 하는 말이네요 :P ) 21:15:19 <zzz> 그러니까 str4d와 sadie가 비공개 병렬 프로젝트 관리 시스템을 실험으로 구축한 거죠. 흥미롭긴 하지만, 그게 제가 하는 일과 어떻게 연결되는지, 제가 계속해야 하는지는 분명하지 않습니다 21:15:55 <str4d> zzz, 그건 큰 그림의 한 부분입니다 21:16:28 <str4d> 위에서 말했듯, 월례 회의에서 "왜 이걸 못 했나요"를 하는 건 우리가 생각했던 만큼 유용하지 않은 것 같습니다 21:16:35 <zzz> 그래서, 제 포럼과 월례 회의에서의 망신주기 방식 프로젝트 관리는 실패로 선언하려 합니다 21:16:50 <str4d> 첫 3주 동안 아무것도 안 했다면, 마지막 주에 해낼 가능성은 높지 않거든요 21:17:21 <str4d> 그래서 보류 중인 항목이 있는 사람들에 대한 더 잦은 빠른 점검이 더 낫다고 봅니다. 그걸 sadie와 시험 중입니다 21:17:34 <zzz> 현 시점에서 comradenosebleed의 초안을 다시 받는다거나, CoC, 웹의 사용 사례, Android 릴리스를 받는 건, 아무리 먼 날짜를 잡아도 특정 날짜까지는 어려울 것 같아요 21:18:10 <zzz> 그래서 월례 액션 아이템 리뷰는 중단하자고 제안합니다. 늘 그렇듯 오픈소스에서는 사람들은 하고 싶은 걸 하게 되고, 여기서는 누구에게 뭘 하도록 설득하는 게 매우 매우 어렵습니다. 21:18:36 <zzz> 사람들은 하고 싶은 걸 할 것이고, 제가 가진 당근과 채찍은 효과적이지 않습니다 21:19:50 <str4d> 월례 회의는 유지하자는 쪽에 투표합니다. 지난달에 실제로 된 일과 벌어진 일(예: kytv 이후 .26에 대해 방금 우리가 한 것)에 기반해 우선순위를 계속 조정하는 데 쓰죠 21:20:56 <susbarbatus> 그럼, 현재 bounty 시스템은 어떻게 되고 있나요? 예: 유료 인센티브가 있는 깔끔히 요약된 공개 목록. 아직 사람들이 보고 있나요? 21:20:59 <susbarbatus> 한 가지 더; 작업별 마이크로페이먼트는 어떤가요. 21:21:03 <str4d> 한편 누군가 무언가를 하기로 했다면, 진행 상황을 sadie에게 알리겠다는 데도 동의해야 합니다. 적어도 sadie가 독촉할 수 있는 커뮤니케이션 채널은 줘야죠 :P 21:21:21 <zzz> 그럼 저는 프로젝트 매니저에서 물러나고, 어떤 시스템과 사람으로 대체할지(TBD)는 추후 결정하자고 제안합니다. 월례 회의는 하되 액션 아이템 리뷰는 없이요 21:21:54 <zzz> 다음 회의는 5월 3일 화요일입니다 21:21:58 <zzz> 5) 관련해 더 있나요 21:22:10 <zzz> 이 회의에 대해 더 있나요? 21:22:35 <str4d> 저는 없습니다 21:22:53 <zzz> 모두들 감사합니다, 오늘은 긴 회의였네요 21:22:58 * zzz *bafs* 회의 종료