Cuộc họp nhà phát triển I2P - 07 tháng 4 năm 2016

20:00:05 <zzz> 0) Chào 20:00:05 <zzz> 1) Các mục còn mở từ các cuộc họp trước http://zzz.i2p/topics/2093 20:00:05 <zzz> 2) Thay thế các vai trò và dịch vụ của kytv http://zzz.i2p/topics/2098 20:00:05 <zzz> 3) Cập nhật kế hoạch 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:00:05 <zzz> 4) Lập kế hoạch HOPE http://zzz.i2p/topics/1968 20:00:05 <zzz> 5) Đánh giá ngắn các cuộc họp hàng tháng và quản lý dự án sau 3 tháng 20:00:10 <zzz> 0) Chào 20:00:12 <zzz> chào 20:00:38 <zzz> 1) Các mục còn mở từ các cuộc họp trước http://zzz.i2p/topics/2093 20:00:55 <orignal_> chào 20:01:00 <zzz> - Chuẩn bị chiến dịch Reseed, trước cuối tháng 1: 20:01:00 <zzz> ** Sadie liên hệ backup để thảo luận OPEN, ngày mới 5 Tháng 4 20:01:11 <zzz> sadie, tình trạng? 20:02:10 <zzz> - Tăng cường mạng - trang chủ và các trang bổ sung 20:02:10 <zzz> ** str4d, gravy, cacapo: Thêm use case, chúng ta giỏi nhất ở điều gì, thêm "passion" và "fat", thêm / làm nổi bật Bote, trước cuối tháng 1 OPEN, str4d thêm use case lên website trước 6 Thg 3, thêm thay đổi về "passion" v.v. trước 5 Thg 4 20:02:15 <zzz> str4d, tình trạng? 20:03:06 <zzz> - Thêm I2P "Story" / lịch sử / vì sao 20:03:06 <zzz> ** comraden chỉnh sửa / trau chuốt / nâng cấp / đăng trước cuối tháng 2 OPEN, ngày mới 1 Thg 4, bản nháp gửi lại zzz trước giữa tháng 3 20:03:11 <zzz> comradenosebleed, tình trạng? 20:03:34 <str4d> chào 20:04:40 <zzz> Quản lý ticket (phiếu công việc) - hiện ad hoc 20:04:40 <zzz> ** Sadie xem xét, đưa khuyến nghị hoặc có thể bắt đầu quản lý chúng (khi nào?) OPEN, str4d và sadie lên lịch họp hoặc làm báo cáo trước 5 Thg 4(?) 20:04:50 <zzz> sadie, str4d: tình trạng? 20:05:49 <hottuna> chào 20:05:59 <zzz> str4d OPEN - phát hành Android 0.9.24 ngày 3 Thg 3, tổng hợp danh sách TODO trước 6 Thg 3, bản nháp lộ trình trước 6 Thg 3, xem xét 5-6 Thg 3 20:06:05 <zzz> str4d, tình trạng? 20:06:33 <str4d> Chúng tôi đã thảo luận 20:06:41 <str4d> (xin lỗi, đang làm 2 cuộc họp cùng lúc) 20:06:54 <zzz> str4d và zzz xem xét ticket VRP trước 12 Thg 2; Sẽ đưa ra một số quyết định trong các cuộc họp lộ trình 5-6 Thg 3 (zzz xong 8 Thg 2, str4d trước 6 Thg 3) 20:06:56 <str4d> liên quan: tickets 20:06:57 <zzz> str4d, tình trạng? 20:07:29 <zzz> sadie và anonimal quay lại với các chỉnh sửa CoC (Bộ quy tắc ứng xử) dựa trên Monero 0mq tại cuộc họp ngày 5 Thg 4 20:07:36 <zzz> sadie, anonimal: tình trạng? 20:08:25 <str4d> Tôi đã quyết định trước đây dùng trạng thái "new" cho các ticket cần phân loại, và tôi vẫn nghĩ đó là hướng nên làm 20:09:00 <str4d> Tôi cũng nghĩ có thể thiết lập một khung giờ thường xuyên cho vài người trong chúng ta cùng duyệt các ticket này 20:09:09 <str4d> liên quan: android 20:09:59 <str4d> Chưa xảy ra vì đang bị chặn bởi build script 20:10:17 <eche|on> uhh 20:10:54 <str4d> Ticket VRP: chưa làm vì tôi bị ốm đúng lúc dự định làm 20:11:00 <zzz> rõ ràng phong cách quản lý dự án hiện tại không hiệu quả vì chẳng có gì diễn ra. Chúng ta tiếp tục, và tôi đưa 5) vào chương trình nghị sự để quyết định có tiếp tục họp hàng tháng hay không 20:11:10 <zzz> gần như tất cả các mục này đã 3 1/3 tháng 20:11:19 <str4d> Điều ĐÃ xảy ra, không có trong danh sách của zzz, là tôi đã hoàn tất di trú spec và đang di trú proposals 20:11:37 <zzz> tin tuyệt vời về specs/proposals, làm tốt lắm 20:12:09 <str4d> Vậy tôi cho rằng nói "không có gì" là không đúng, chỉ là chuyển ưu tiên mà chưa phản ánh trong phong cách PM hiện tại 20:12:17 <str4d> Vậy vâng, chúng ta cần tinh chỉnh 20:12:20 <zzz> ok. góc nhìn hay 20:12:25 <zzz> còn gì nữa ở 1) ? 20:13:04 <str4d> Với mọi người ở đây, phần proposals ở http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals - vui lòng xem và nhận xét :) 20:13:26 <zzz> 2) Thay thế các vai trò và dịch vụ của kytv http://zzz.i2p/topics/2098 20:13:34 <zzz> có danh sách khoảng 20 việc anh ấy đã làm 20:13:44 <str4d> Tôi không còn gì thêm 20:13:47 <str4d> (Tôi có làm I2P Android, chỉ là chưa kịp phát hành) 20:13:55 <zzz> Tôi tập trung vào những ưu tiên cao nhất - launchpad và debian 20:14:14 <zzz> một số người khác đang nghiên cứu các thứ khác, và chúng tôi đã hoán đổi vài liên kết trang chủ console trong .25 20:14:33 <zzz> với tôi thì việc quan trọng tiếp theo là người duy trì Tails 20:15:06 <zzz> có ai ở đây biết Tails VÀ đóng gói Debian và có thể giúp không? nếu không, tôi sẽ kêu gọi trên twitter ngay 20:15:24 <zzz> chúng ta sẽ bị loại khỏi Tails sớm nhất là bản phát hành tiếp theo trong hai tháng nữa 20:15:32 <zzz> 2.4 tôi tin vậy 20:15:50 <zzz> nó quá sức tôi. Tôi sẽ không làm việc đó. 20:16:02 <str4d> Ugh 20:16:19 <str4d> Tails yêu cầu tối thiểu những gì 20:16:19 <str4d> ? 20:16:20 <zzz> công việc là lấy gói Debian tôi làm, tinh chỉnh/chèn vào Tails, test test test, cộng thêm một số ticket i2p của Tails hiện có 20:16:49 <zzz> tôi nghĩ có một bài viết dài kytv đã làm, nó được liên kết từ chủ đề kytv trên zzz.i2p 20:17:04 <zzz> về cơ bản đầu vào cho Tails là một gói deb 20:17:19 <zzz> nhưng tôi nghĩ họ có một đống bất bình tích tụ 20:17:25 <eche|on> kêu gọi trên twitter 20:17:33 <str4d> +1 trên Twitter 20:17:35 <zzz> có ai khác có gì để báo cáo về phần thay thế kytv không? 20:18:07 <str4d> Tôi chưa tiến triển thêm với máy chủ Buildbot CI kể từ lần tôi nhắc tới trên IRC một hai tuần trước 20:18:23 <str4d> Tôi sẽ làm thêm việc đó cuối tuần này 20:18:42 <zzz> ok. danh sách còn nhiều, hãy mỗi người chọn một thứ quan trọng. 20:19:02 <zzz> lần gọi cuối cho 2) 20:19:46 <str4d> Nếu không ai làm, tôi CÓ THỂ nhận IRC bot/relay. Hiện giờ thì khó. 20:20:34 <zzz> tôi nghĩ các bản build deb khá ổn nhưng vẫn còn vài thứ như arm cho jessie mà tôi có thể đã sửa hôm nay, cũng có thể chưa 20:21:19 <zzz> 3) Cập nhật kế hoạch 0.9.26 http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960 20:21:33 <zzz> ok tôi muốn làm 3a) lịch trình rồi 3b) GMP 6 20:21:38 <zzz> 3a) lịch trình 20:22:03 <zzz> lộ trình ghi 'tháng 5' và 6-7 tuần từ bản phát hành trước 22 Thg 3 sẽ là đầu-trung tháng 5 20:22:36 <zzz> ở các cuộc họp lộ trình một tháng trước, chúng ta có một kế hoạch tham vọng bao gồm cả addressbook subscription protocol (giao thức đăng ký sổ địa chỉ) 20:23:16 <zzz> nhưng tất cả đổ bể hôm sau khi mọi thứ của kytv sập và có vẻ ít khả năng anh ấy quay lại 20:23:36 <zzz> vậy nên tôi chưa bắt đầu gì liên quan tới 26. 2-3 tuần qua tôi toàn thời gian làm việc Debian/launchpad 20:24:01 <str4d> khoảng bảy tuần nữa là cuối tháng 5. Bạn nghĩ có khả thi không? 20:24:15 <str4d> (Giờ chuyện debian phần lớn đã trong tầm kiểm soát) 20:24:19 <zzz> như vậy sẽ đẩy 26 sang có lẽ tháng 6, và sẽ trễ hạn Tails 2.4 20:24:37 <str4d> Ugh 20:24:37 <zzz> cuối tháng 5 có thể, nhưng ngày càng ít khả năng 20:24:42 <str4d> Hạn của tails là khi nào? 20:25:11 <zzz> không biết ngay. Tôi đã yêu cầu họ tự kéo 25 vào (họ đã từ chối một lần) 20:25:23 <eche|on> Tôi nghĩ tháng 6 là ổn, vì tails đang on the judge hiện tại 20:25:45 <zzz> họ không có khả năng nhìn thấy mức sử dụng i2p trên tails và không nghe thấy đòi hỏi ồn ào nào, nên họ thấy nó rắc rối nhiều hơn giá trị 20:26:18 <eche|on> yeas 20:26:33 <zzz> bình thường với một tính năng lớn như addressbook subscription protocol, tôi sẽ xong nó một tuần trước bản phát hành TRƯỚC, sẵn sàng prop (propagate trong Monotone) 20:26:54 <zzz> vậy là chậm 3 tuần, cộng thời gian phát triển tối thiểu vài tuần nữa, tổng chậm khoảng 5 tuần 20:27:39 <zzz> đó là tình hình. Tôi chưa đẩy gì ra lộ trình chính thức, nhưng sẽ cần sớm làm 20:27:49 <zzz> còn gì nữa ở 3a) lịch trình? 20:27:58 <str4d> Chúng ta đã dự định đưa gì vào bản 0.9.27 thực tế? 20:28:16 <zzz> xem liên kết lộ trình phía trên 20:28:31 <zzz> early ntcp2/dh/pt 20:29:18 <str4d> Tôi vẫn nghĩ mọi thứ cần diễn ra theo thứ tự ở đó, vậy cái chúng ta CÓ THỂ làm là đẩy address subscription protocol sang 0.9.27 20:29:27 <str4d> Như vậy bạn có tháng 5 để làm nó 20:29:47 <zzz> nhưng chưa có .26. chưa có gì xảy ra. trong đó chỉ có thay đổi deb 20:29:50 <str4d> Và .26 có thể là CRLs và một ít dọn dẹp tổng quát 20:30:08 <zzz> cho đến khi ai đó (bao gồm cả tôi) làm gì đó, sẽ chẳng có gì để phát hành 20:30:27 <zzz> vậy xem sao. Tôi cũng phải nghỉ vài ngày để làm thuế :) 20:30:37 <zzz> còn gì nữa ở 3a) lịch trình? 20:30:55 <eche|on> đừng quá bám chặt lịch đã lên 20:30:56 <str4d> Tôi có vài tinh chỉnh UI ban đầu xuất phát từ các thảo luận giữa tôi và sadie mà tôi có thể áp dụng 20:31:20 <zzz> 3b) GMP 6 20:31:25 <str4d> (không phải thiết kế lại lớn tôi đang lên kế hoạch mà chỉ là tinh chỉnh tổng thể) 20:31:50 <zzz> sau khoảng 15 tháng làm, tuna và tôi gần sẵn sàng prop nhánh gmp6 sang trunk cho 26 20:32:05 <zzz> tuna có khoảng trăm binary đã build trong 6 tháng qua, chờ checkin 20:32:25 <zzz> build bằng nhiều cách - vms, native, microsoft, máy mượn, v.v. 20:32:53 <zzz> theo truyền thống chúng tôi checkin ghi chú chi tiết về môi trường build (phiên bản compiler, chi tiết hệ điều hành, v.v.) cho mỗi binary được checkin 20:33:13 <zzz> không may, tuna không giữ bản ghi nào của bất kỳ build nào. 20:34:06 <zzz> vậy câu hỏi là, chúng ta có bắt đầu lại (có thể tốn 6 tháng), hay tôi chỉ build các binary linux và bỏ qua phần còn lại, hay là chúng ta thật sự không cần các ghi chú này và cứ tiến hành nhận tất cả những gì tuna đã làm? 20:34:08 <eche|on> có cơ hội làm lại không? 20:34:47 <zzz> tuna nói là không thể. ai cũng có thể build các binary linux 32/64. nhưng phần còn lại có vấn đề 20:35:00 <eche|on> câu hỏi hay, trường hợp này: làm lại hoặc nhận, không có đường ở giữa 20:35:25 <eche|on> chúng ta cần gmp cho mac, win và arm 20:35:29 <zzz> lần cuối tuna nói với tôi là lấy hoặc bỏ, anh ấy xong rồi 20:35:54 <zzz> ngay cả khi build nhanh, kiểm thử thì chậm 20:36:25 <str4d> Chúng ta có viết quy trình kiểm thử đâu đó không? 20:36:54 <zzz> nếu bạn vào trang cuối của http://zzz.i2p/topics/1960 anh ấy đã nộp tất cả ghi chú build mà anh ấy có 20:36:56 <eche|on> (chỉ để nhắc, chúng ta đã chấp nhận vài thứ khác không có ghi chú rồi) 20:37:07 <str4d> vì điều này nghe chính xác là thứ chúng ta nên đưa vào máy chủ CI 20:37:38 <zzz> anh ấy đã cập nhật readme về cách build. có một ít thông tin trong chủ đề về cách test, và tôi cũng đã phát triển phương pháp riêng 20:38:07 <zzz> nhớ là anh ấy đã phát hành 13 phiên bản bộ sưu tập binary trong 6 tháng qua 20:38:36 <zzz> hottuna, bạn có gì bổ sung không? 20:38:37 <str4d> Nếu ai đó có thể viết phương pháp kiểm thử, tôi có thể chuyển nó thành một loại build trong Buildbot 20:38:58 <str4d> Sau đó chỉ còn tìm máy để nối vào. 20:39:08 <hottuna> chờ chút 20:39:24 <str4d> Tôi nghĩ có lẽ chúng ta nên đầu tư một máy Mac để chạy đâu đó như buildslave 20:39:44 <hottuna> eche|on: về rebuild: không phải không thể, nhưng giờ quá nhiều việc với tôi. quá xa. 20:40:02 <str4d> không cần quá đắt, nhưng cái chúng ta có thể thực sự dùng để hoàn thành bộ ba (chúng ta sẽ có buildslave linux và windows khi tôi xử lý xong VM với eche) 20:40:10 <eche|on> hottuna: có cách nào howto rebuild không? 20:40:27 <zzz> ngay cả nếu build cho tất cả 100 tệp diễn ra vào ngày mai, sẽ mất 3 tháng để test 20:40:39 <hottuna> có tài liệu readme mà _should_ chứa mọi thứ bạn cần. 20:40:48 <str4d> Tối thiểu thì chúng ta đã hưởng lợi từ các cải tiến script khác nhau của hottuna 20:41:10 <str4d> Nhưng câu hỏi khác là, nếu rebuild bây giờ, chúng ta có nhảy lên 6.1 không 20:41:11 <zzz> ngoài ra còn có thay đổi lớn trong chính mã cpuid 20:41:23 <hottuna> str4d: các script chưa hoàn hảo giờ, nhưng dù sao cũng tốt hơn. 20:41:23 <zzz> đúng, có thể 6.1 20:41:25 <str4d> Yep 20:41:30 <hottuna> str4d: nếu rebuild, chúng ta nên nhảy lên 6.1 20:41:44 <eche|on> code mới chạy ổn chứ? 20:41:57 <hottuna> eche|on: theo như chúng ta biết thì không có bug (hah!). 20:42:07 <zzz> dĩ nhiên với build debian, chúng ta link động, nên bạn sẽ nhận 6.1 nếu được cài (và điều đó nhắc tôi, chúng ta chưa test thư viện động gmp 6) 20:42:10 <str4d> Tôi chỉ không chắc các script cần đổi bao nhiêu để làm 6.1, nhưng hy vọng là gần như drop-in 20:42:14 <eche|on> nếu test ổn, đưa vào. và hãy rebuild với 6.1 ở một kênh phụ và để thông tin vào sau 20:42:38 <eche|on> như tôi thấy, chúng ta đã test nó khá tốt rồi 20:42:51 <hottuna> eche|on: phần khó không phải chạy các script. Lấy máy, dựng môi trường và test mới là phần khó/chậm 20:43:03 <eche|on> đúng 20:43:13 <str4d> hottuna, đó là thứ tôi muốn đưa vào CI 20:43:15 <zzz> quay lại câu hỏi ban đầu. Chúng ta muốn vứt 6 tháng công sức (thực ra làm từ đầu 2015) hay chấp nhận các binary hiện có, không có ghi chú chi tiết 20:43:25 <str4d> Bạn nghĩ đã dùng bao nhiêu máy khác nhau? 20:43:37 <zzz> tạm gác CI v.v. lúc này và quyết xem chúng ta có vấn đề hay không 20:43:52 <hottuna> str4d: chủ yếu là drop-in, thêm một hai target. không có lý do để không hỗ trợ các kiến trúc mới nhất mà gmp hỗ trợ 20:44:13 <str4d> zzz, tôi nghiêng về việc chấp nhận binary với điều kiện chúng ta sẽ di trú lên 6.1 20:44:24 <hottuna> str4d: ~6 môi trường khác nhau 20:44:29 <zzz> 6.1 nằm trong lộ trình cuối năm nay 20:44:39 <zzz> các binary hiện tại là 6.0 20:44:41 <str4d> Hệ quả dây chuyền nếu ta chấp nhận các binary là gì? 20:44:41 <hottuna> str4d: không nhất thiết cần máy khi cross-compiling 20:44:51 <str4d> 1) chúng sẽ nằm trong mtn 20:45:01 <zzz> cũng nhớ là, nó cho tốc độ tăng lớn trên một số phần cứng, và cả constant time 20:45:17 <str4d> 2) chúng được đóng gói vào các tệp cập nhật và cài đặt liên quan 20:45:21 <zzz> 'hệ quả' = điều xấu? 20:45:28 <str4d> 2a) tăng kích thước tệp cập nhật rất nhiều 20:45:44 <str4d> 3) nếu nó lỗi trên một hệ bất kỳ, chuyện gì xảy ra? 20:46:03 <str4d> Chúng ta đã dự định 1) rồi 20:46:26 <zzz> chúng ta chỉ checkin các binary nếu chúng sẽ được prop ngay cho .26. 20:46:28 <str4d> Tương tự 2), nhưng binary 6.0 sẽ được thay bằng 6.1 nên không vấn đề lớn 20:46:37 <str4d> Điều tôi lo là 3) 20:46:43 <zzz> chỉ binary cho phát hành mới được checkin 20:47:00 <str4d> 3a) có code hiện có nào để kiểm tra trạng thái lỗi không? 20:47:04 <zzz> 3) là rủi ro chung cho bất kỳ thay đổi nào 20:47:19 <zzz> lỗi trong gmp thường là crash JVM 20:47:26 <str4d> 3b) Có cách rơi về libjbigi cũ còn hoạt động không? 20:47:44 <str4d> (tự động hoặc thủ công) 20:48:00 <str4d> Chúng ta có thể, ví dụ, đổi tên libjbigi cũ để nếu có vấn đề, có thể bảo người dùng "hãy đổi tên tệp này" 20:48:22 <zzz> str4d, bạn đang cân nhắc liệu chúng ta có nên bao giờ thay jbigi không? đây là tác động chung khi thay gmp 20:49:14 <str4d> zzz, mối lo của bạn là không biết nguồn gốc chính xác của các binary này. Tôi giả định vậy thì nếu có vấn đề, sẽ khó lần ra nguồn hơn. 20:49:27 <str4d> Nên tôi đang nghĩ tới chiến lược giảm thiểu 20:50:00 <zzz> chúng ta có thể không đưa jbigi.jar vào bản cập nhật 26, vậy chỉ cài đặt mới mới nhận. Như vậy rollout sẽ chậm hơn. 20:50:25 <zzz> cài đặt mới + launchpad/deb 20:50:57 <zzz> cách sửa chung là xóa libjbigi.so và jbigi.jar, rồi bạn chạy không có 20:51:01 <str4d> Điều đó có lẽ cũng hay 20:51:30 <str4d> Triển khai cho cài đặt mới, và nếu không nghe vấn đề gì, triển khai trong cập nhật ở bản kế tiếp. 20:51:43 <zzz> Tôi đoán ý của tuna là chẳng có gì có thể tái tạo. Tất cả là máy mượn và VM đã mất 20:52:23 <zzz> eche|on, thông tin hệ thống và msvc từ máy mà hottuna dùng để build win có sẵn không? 20:53:10 <zzz> tuna không xung phong nghiên cứu gì cả nhưng anh ấy không mượn laptop của sadie sao? hay tất cả vô ích vì có thể đã nâng cấp trong lúc đó? 20:53:24 <eche|on> anh ấy có quyền truy cập máy win 10 trên host kvm của tôi. Tôi có thể đăng nhập và kiểm tra 20:53:33 <str4d> Ừm, đó là lý do tôi muốn làm build 6.1 trong Buildbot với buildserver mà ta có thể theo dõi. 20:53:57 <hottuna> zzz: tôi mượn hai máy osx khác nhau của bạn 20:53:58 <eche|on> Tôi không thay đổi vm chút nào 20:54:33 <zzz> chưa ai tình nguyện nhận một máy mac miễn phí chúng ta trả tiền, vì không ai muốn làm 'mac guy' 20:54:51 <zzz> vậy thật ra thiếu thời gian và con người, không phải tiền 20:55:17 <hottuna> zzz: Tôi chỉ không muốn mấy thiết bị phải vác theo. 20:56:01 <zzz> đây là ghi chú build đầy đủ của hottuna: 20:56:03 <zzz> Ghi chú build 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> Ghi chú build 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> như vậy đủ chưa hay chúng ta bắt đầu lại? 20:57:14 <str4d> Xét rằng chúng ta sẽ di trú lên 6.1 vào cuối năm, và các binary này đã được test ở mức hợp lý, tôi nghiêng về nói là ok. 20:57:41 <zzz> ai phản đối không? 20:57:45 <eche|on> ít nhất đó là một khởi đầu, nhưng theo tiêu chuẩn "Tor reproduceable builds" thì chẳng là gì. chúng ta muốn tiêu chuẩn kiểu gì? 20:58:03 <hottuna> không 20:58:34 <eche|on> Tôi muốn đưa chúng vào cài đặt mới với cờ "temp". Tôi biết đó là công việc khó. 20:59:14 <zzz> cơ bản thì việc test hiện tại tụt về 0. Cách duy nhất để có thêm test là đưa chúng vào trunk, và phát hành. 20:59:17 <susbarbatus> Xin lỗi chen ngang; Tôi có nhiều máy mac, và không có vấn đề gì để làm mac hoặc bsd guy. Nếu ai đó có thể nói cho tôi cần gì sau cuộc họp, tôi có thể đánh giá xem có thể đóng góp nếu tôi đủ hiểu biết / có thể học được. 20:59:29 <zzz> tuyệt vời susbarbatus 20:59:44 <str4d> susbarbatus, như vậy thì tuyệt 20:59:47 <zzz> ok vậy hãy nhờ hottuna checkin chúng 20:59:53 <eche|on> zzz: ừ, chúng ta chưa bao giờ nói phát hành là 100% an toàn và hoàn chỉnh^^ 21:00:05 <zzz> hottuna, nhánh là i2p.i2p.str4d.gmp6 (KHÔNG PHẢI i2p.i2p.zzz.gmp6) 21:00:17 <hottuna> ok 21:00:38 <zzz> hottuna, đừng quên mtn drop những cái cần xóa. Khi xong, thư mục phải khớp chính xác với những gì trong zip v13 của bạn 21:00:50 <zzz> còn gì nữa ở 3b) ? 21:00:55 <hottuna> bạn có muốn xóa jcpuid/binary cũ cho các nền tảng chúng ta không build không? 21:01:09 <str4d> susbarbatus, điều tôi muốn thiết lập là một buildserver, nếu bạn có thể cam kết có một máy mac luôn chạy và sẵn sàng cho các câu hỏi/hỗ trợ khi có lỗi. Nói chung sẽ không cần bạn tham gia nhiều, vì buildserver sẽ được điều khiển tự động :) 21:01:28 <zzz> Tôi tin đề xuất của hottuna là v13 _exactly_ là thứ sẽ phát hành, không hơn, không kém. 21:01:38 <zzz> nếu bạn muốn chúng ta có thể xem lại sau cuộc họp 21:01:38 <str4d> Hoặc nếu không luôn chạy, ít nhất dễ khởi động trong cấu hình buildserver 21:01:51 <hottuna> zzz: tuyệt 21:01:54 <str4d> (buildmaster sẽ xử lý các buildserver không luôn online) 21:02:12 <zzz> gác chuyện buildserver lại và chuyển sang 4) 21:02:22 <zzz> 4) Lập kế hoạch HOPE http://zzz.i2p/topics/1968 21:02:23 <susbarbatus> str4d: không vấn đề. Tôi có thể gắn con mac mini ~2012 của tôi cho việc đó. Nó chậm nhưng sẽ không làm gì khác. 21:02:24 <str4d> ACK 21:02:33 <str4d> ^5 susbarbatus :) 21:02:52 <eche|on> hope - Tôi có một vé để dùng 21:02:57 <zzz> Tôi đã gặp Lance tuần này. đề xuất vẫn là anh ấy cấp một phòng hội thảo nhỏ cả ngày, hoặc ngày trước hoặc sau HOPE 21:03:04 <zzz> tức là 21 hoặc 25 tháng 7 21:03:22 <zzz> Tôi nhấn mạnh với anh ấy rằng chúng ta cần ngày và cam kết sớm, để có thể mua vé máy bay 21:03:46 <zzz> việc này sẽ không mở công chúng. chỉ mời, 5-6 người, chỉ là chỗ tụ họp cho các cuộc họp lộ trình v.v. 21:03:51 <str4d> Lúc này tôi không thể cam kết có mặt, dù có một cơ hội nhỏ là tôi có thể ở Mỹ lúc đó 21:04:00 <zzz> cộng thêm chúng ta trình bày với anh ấy những gì chúng ta làm và ngược lại 21:04:30 <zzz> hiện tôi có tôi và sadie là chắc chắn, với comradenosebleed và lazygravy là có thể. Còn ai nữa? 21:04:49 <zzz> và hạn chót cứng khi bạn cần chốt phương án đi lại là khi nào? 21:05:33 <zzz> nếu chỉ có tôi và sadie thì có lẽ hủy cả, nhưng xem đã 21:05:39 <zzz> ai không? 21:06:04 <zzz> hottuna đến chứ? 21:06:07 <str4d> (tất cả phụ thuộc vào khi nào bảo vệ luận án của tôi được ấn định, chưa biết khi nào) 21:06:09 <str4d> (và cả các vấn đề visa khác) 21:06:17 <str4d> Nếu bảo vệ luận án trước đó, tôi muốn có mặt (dù chỉ là bay ngang qua) 21:06:17 <eche|on> Tôi quan tâm, nhưng không đủ khả năng trả tiền bay và khách sạn. đặc biệt nếu chúng ta gặp nhau muộn hơn ở can 21:06:17 <str4d> Vậy hỏi tôi lại sau khoảng một tháng 21:06:45 <zzz> ok, tôi sẽ tiếp tục hối Lance chốt lại, và hy vọng mọi người sẽ xuất hiện 21:06:50 <zzz> lần gọi cuối cho 4) 21:07:00 <hottuna> zzz: thời gian rất khó cho tôi. tôi phải ở EU vào Jul16 để dự đám cưới. 21:07:15 <hottuna> Tôi không dám cam kết lúc này. 21:07:20 <zzz> tuyệt, đi qua nyc trên đường về :) 21:07:26 <hottuna> (hoặc nếu phải quyết bây giờ thì thôi) 21:07:33 <hottuna> hmmph.. 21:07:44 <hottuna> không tệ lắm 21:07:47 <zzz> 5) Đánh giá ngắn các cuộc họp hàng tháng và quản lý dự án sau 3 tháng 21:07:59 <str4d> Vậy hãy ghi tôi là hy vọng cho buổi meetup, và khó có khả năng cho HOPE (vì tôi không thể cam kết cần vé, nhưng sẽ dùng một vé dư nếu tôi tình cờ ở đó) 21:08:26 <zzz> ok, theo góc nhìn của tôi việc này không hiệu quả chút nào, gần như không có hạng mục hành động nào hoàn tất, vậy liệu có sửa được không hay chúng ta nên dừng họp hàng tháng? 21:08:40 <str4d> Tôi nghĩ có thể sửa 21:08:42 <zzz> nếu không ai làm gì, chẳng có gì để quản lý. Không tệ đến mức đó nhưng gần rồi 21:09:11 <str4d> Ít nhất thì tôi nghĩ các cuộc họp hàng tháng là hữu ích 21:09:30 <zzz> mục tiêu còn là chuyển quản lý dự án cho sadie nhưng cô ấy thậm chí không tham dự họp nên việc đó cũng không đúng tiến độ 21:09:32 <hottuna> Tôi đồng ý về điều đó 21:09:44 <str4d> Cô ấy tưởng là sớm hơn một giờ 21:09:49 <str4d> Cô ấy đang ở cuộc họp khác 21:10:19 <str4d> (cô ấy đến sớm một giờ và không ai nói ở đây) 21:10:41 <zzz> đúng, ai cũng thích họp khi không phải điều hành. Nhưng tôi trông như thằng ngốc mỗi tháng đi hỏi liệu thứ ai đó hứa 3 tháng trước đã xong chưa. Tôi mệt rồi. 21:10:49 <str4d> Tôi đã bàn với sadie, và giờ chúng tôi có các cuộc họp hàng tuần để đảm bảo đi đúng hướng với các hạng mục cả hai đang làm 21:11:19 <str4d> zzz, vậy đừng đặt trọng tâm cuộc họp là "bạn đã làm thứ này chưa" 21:11:36 <zzz> có lẽ điều này quá bi quan nhưng với sự thiếu tiến triển và kytv biến mất tôi nghĩ chúng ta gặp rắc rối lớn 21:11:40 <hottuna> zzz: dự kiến chuyển cho sadie khi nào? 21:11:40 <str4d> Tôi nghĩ họp hàng tháng nên để đánh giá lại ưu tiên và tổ chức lại 21:11:58 <zzz> ok vậy làm sao giữ mọi người đi đúng kế hoạch làm điều họ hứa? 21:12:13 <str4d> trong khi việc "bạn đã làm thứ này chưa" cần a) trách nhiệm cá nhân hơn và b) tương tác một-một nhiều hơn 21:12:30 <hottuna> zzz: không tuyệt gì, nhưng nói rắc rối lớn có lẽ là quá 21:13:02 <str4d> zzz, với tôi, tôi đã thiết lập họp hàng tuần với sadie để giúp tôi đi đúng nhịp, và cho cô ấy quyền truy cập danh sách việc cần làm I2P của tôi để cô ấy giúp ưu tiên 21:13:07 <susbarbatus> str4d: Tôi nghĩ ý là, nếu ai cũng giữ lời hứa/cam kết thì zzz đã không phải hỏi câu đã làm chưa ;). 21:13:12 <str4d> (mới chỉ có một cuộc họp, nên tôi vẫn cần xem nó hoạt động thế nào) 21:13:17 <str4d> susbarbatus, đúng vậy 21:13:50 <str4d> Chúng ta cần linh hoạt đủ để xử lý thực tế là mọi người làm việc này vì vui/tình nguyện ngoài công việc chính 21:14:13 <zzz> đúng. Hệ thống của tôi hiện là khi bạn hoàn tất thứ gì, bạn báo cáo trên chủ đề zzz.i2p cho cuộc họp, để chúng ta KHÔNG phải tốn thời gian họp cho nó 21:14:15 <str4d> Nhưng cũng cần nhấn mạnh rằng nếu ai đó không làm việc, họ đang không giúp ích 21:14:28 <zzz> chỉ khi mọi người không hoàn tất và không báo cáo thì chúng ta mới phải tốn thời gian ở đây 21:14:42 <str4d> và tốt hơn là chuyển hạng mục cho người khác hơn là chặn vô thời hạn 21:14:54 <str4d> (nói bởi người hiện đang chặn vô thời hạn ở I2P Android :P ) 21:15:19 <zzz> vậy str4d và sadie đã thiết lập một hệ thống quản lý dự án song song, không công khai như một thử nghiệm. thú vị, nhưng tất nhiên không rõ nó liên quan gì tới những gì tôi đang làm, hay tôi có nên tiếp tục làm hay không 21:15:55 <str4d> zzz, đó là một phần trong bức tranh lớn hơn 21:16:28 <str4d> Như tôi nói, cố gắng làm phần "vì sao bạn không làm cái này" trong cuộc họp hàng tháng không hữu ích như chúng ta nghĩ 21:16:35 <zzz> vậy quản lý dự án qua diễn đàn của tôi và việc nhắc nhở trong các cuộc họp hàng tháng, tôi sẵn sàng tuyên bố thất bại 21:16:50 <str4d> vì nếu họ không làm gì trong ba tuần đầu, khó mà làm xong tuần cuối 21:17:21 <str4d> do đó tôi nghĩ kiểm tra nhanh thường xuyên với người có hạng mục đang chờ thì tốt hơn, đó là điều tôi đang thử với sadie 21:17:34 <zzz> tới thời điểm này tôi không nghĩ mình sẽ nhận lại bản nháp từ comradenosebleed, hay một CoC, hay các use case trên web, hay một bản phát hành android, ít nhất không vào một ngày cụ thể nào đó cho dù xa đến đâu 21:18:10 <zzz> vậy tôi đề xuất dừng việc rà soát hàng tháng các hạng mục hành động. Như thường lệ, mọi người sẽ làm hoặc không làm những gì họ muốn trong open source, và rất rất khó để thuyết phục ai làm điều gì ở đây. 21:18:36 <zzz> mọi người sẽ làm điều họ muốn, và bất kỳ củ cà rốt hay cây gậy nào tôi có cũng không hiệu quả 21:19:50 <str4d> Tôi bỏ phiếu giữ các cuộc họp hàng tháng, và dùng chúng để điều chỉnh ưu tiên dựa trên những gì ĐÃ làm và những gì đã xảy ra trong tháng qua (vd. những gì chúng ta vừa làm về .26 sau kytv) 21:20:56 <susbarbatus> Vậy, hệ thống bounty giờ hoạt động thế nào? Ví dụ, đó là một danh sách công khai tóm tắt với động lực trả tiền. Mọi người còn xem nó không? 21:20:59 <susbarbatus> Tôi muốn đề cập; còn micropayments cho các tác vụ thì sao. 21:21:03 <str4d> trong lúc đó nếu ai đồng ý làm gì đó, họ cũng nên đồng ý cập nhật cho sadie về tiến độ, hoặc ít nhất cho sadie một kênh liên lạc để nhắc nhở họ :P 21:21:21 <zzz> ok vậy tôi đề xuất từ chức quản lý dự án, được thay bằng một hệ thống và người TBD. Chúng ta sẽ họp hàng tháng nhưng không rà soát hạng mục hành động 21:21:54 <zzz> cuộc họp tiếp theo sẽ là Thứ Ba, 3 Thg 5 21:21:58 <zzz> còn gì nữa ở 5) 21:22:10 <zzz> còn gì nữa cho cuộc họp này? 21:22:35 <str4d> Tôi thì không 21:22:53 <zzz> cảm ơn mọi người, cuộc họp dài hôm nay 21:22:58 * zzz *bafs* cuộc họp kết thúc