त्वरित पुनरावलोकन

उपस्थित: eche|on, hottuna, orignal, str4d, susbarbatus, zzz

बैठक लॉग

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_> हाय 20:01:00 <zzz> - Reseed अभियान की तैयारी, जनवरी के अंत तक: 20:01:00 <zzz> ** Sadie बैकअप से संपर्क करेगी ताकि OPEN पर चर्चा हो सके, नई तारीख 5 अप्रैल 20:01:11 <zzz> sadie, स्थिति? 20:02:10 <zzz> - नेटवर्क को सुदृढ़ करना - होम पेज और अतिरिक्त पेज 20:02:10 <zzz> ** str4d, gravy, cacapo: उपयोग के मामले जोड़ें, हम किसमें सर्वोत्तम हैं, अधिक "passion" और "fat", Bote जोड़ें / हाइलाइट करें, जनवरी के अंत तक OPEN, str4d 6 मार्च तक उपयोग के मामले वेबसाइट पर जोड़ेगा, passion आदि पर और बदलाव 5 अप्रैल तक 20:02:15 <zzz> str4d, स्थिति? 20:03:06 <zzz> - I2P "Story" / history / why जोड़ें 20:03:06 <zzz> ** comraden संपादन / पॉलिश / सुधार / पोस्ट फरवरी के अंत तक करेगा OPEN, नई तारीख 1 अप्रैल, ड्राफ्ट mid-March तक zzz को वापस 20:03:11 <zzz> comradenosebleed, स्थिति? 20:03:34 <str4d> हाय 20:04:40 <zzz> टिकट प्रबंधन - वर्तमान में ऐड-हॉक 20:04:40 <zzz> ** Sadie समीक्षा करेगी, सिफारिशें देगी या संभवतः उन्हें मैनेज करना शुरू करेगी (कब तक?) OPEN, str4d और sadie 5 अप्रैल(?) तक बैठक शेड्यूल करेंगे या रिपोर्ट बनाएंगे 20:04:50 <zzz> sadie, str4d: स्थिति? 20:05:49 <hottuna> हाय 20:05:59 <zzz> str4d OPEN - Android 0.9.24 रिलीज़ 3 मार्च, TODO सूची 6 मार्च तक संकलित, रोडमैप ड्राफ्ट 6 मार्च तक, 5-6 मार्च को समीक्षा 20:06:05 <zzz> str4d, स्थिति? 20:06:33 <str4d> हमने इस पर चर्चा की 20:06:41 <str4d> (माफ़ करना, एक साथ 2 बैठकें कर रहा हूँ) 20:06:54 <zzz> str4d और zzz 12 फरवरी तक VRP टिकट की समीक्षा करेंगे; 5-6 मार्च की रोडमैप बैठकों के दौरान कुछ निर्णय लेंगे (zzz ने 8 फरवरी को किया, str4d 6 मार्च तक) 20:06:56 <str4d> टिकटों के बारे में 20:06:57 <zzz> str4d, स्थिति? 20:07:29 <zzz> sadie और anonimal 5 अप्रैल की बैठक में Monero 0mq के आधार पर CoC के संपादन वापस लाएंगे 20:07:36 <zzz> sadie, anonimal: स्थिति? 20:08:25 <str4d> मैंने पहले तय किया था कि जिन टिकटों को ट्रायेज़ की ज़रूरत है उनके लिए "new" स्टेटस रखें, और मुझे अब भी लगता है कि यही तरीका सही है 20:09:00 <str4d> मुझे यह भी लगता है कि हम में से कुछ के लिए इन टिकटों से गुजरने के लिए एक नियमित समय तय करना अच्छा विचार हो सकता है 20:09:09 <str4d> एंड्रॉयड के बारे में 20:09:59 <str4d> अभी तक नहीं हुआ क्योंकि बिल्ड स्क्रिप्ट पर ब्लॉक है 20:10:17 <eche|on> उह्ह 20:10:54 <str4d> VRP टिकट: अभी तक नहीं हुआ क्योंकि जब काम करने की योजना थी तब मैं बीमार था 20:11:00 <zzz> यह स्पष्ट है कि वर्तमान प्रोजेक्ट प्रबंधन शैली काम नहीं कर रही है क्योंकि कुछ हो नहीं रहा। चलिए आगे बढ़ते हैं, और मैंने एजेन्डा में 5) इसलिए रखा है कि तय करें हमें मासिक बैठकें जारी रखनी चाहिए या नहीं 20:11:10 <zzz> इन में से लगभग सभी आइटम 3 1/3 महीने पुराने हैं 20:11:19 <str4d> जो हुआ है, जो zzz की सूची में नहीं है, वह यह कि मैंने spec माइग्रेशन पूरा किया है और प्रस्तावों का माइग्रेशन काफी आगे बढ़ चुका है 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> मैंने Buildbot CI सर्वर पर पिछले हफ्ते या दो हफ्ते पहले IRC में बताने के बाद से कोई और प्रगति नहीं की है 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> रोडमैप में 'मई' लिखा है और पिछले रिलीज़ 22 मार्च से 6-7 हफ्ते शुरुआती-मध्य मई होंगे 20:22:36 <zzz> एक महीने पहले रोडमैप बैठकों में, हमने एक महत्वाकांक्षी योजना बनाई जिसमें addressbook subscription प्रोटोकॉल शामिल था 20:23:16 <zzz> लेकिन यह सब अगले दिन बिखर गया क्योंकि kytv की चीज़ें सब डाउन हो गईं और उसके वापस आने की संभावना कम हो गई 20:23:36 <zzz> इसलिए मैंने अभी तक 26-संबंधित किसी भी चीज़ पर काम शुरू नहीं किया है। पिछले 2-3 हफ्ते फुल-टाइम debian/launchpad काम में गए 20:24:01 <str4d> अभी से ~सात हफ्ते मई के अंत होते हैं। क्या आपको लगता है कि यह संभव होगा? 20:24:15 <str4d> (अब जब debian वाली चीज़ें अधिकांशतः नियंत्रण में हैं) 20:24:19 <zzz> वह 26 को शायद जून तक धकेल देगा, और Tails 2.4 की डेडलाइन से काफी आगे होगा 20:24:37 <str4d> उफ़ 20:24:37 <zzz> मई का अंत हो सकता है, लेकिन दिन-ब-दिन कम संभव होता जा रहा है 20:24:42 <str4d> Tails की डेडलाइन कब है? 20:25:11 <zzz> अभी याद नहीं। मैंने उनसे पहले ही खुद 25 खींचने के लिए फिर से कहा है (उन्होंने पहले ही एक बार मना कर दिया) 20:25:23 <eche|on> मुझे लगता है जून ठीक है, क्योंकि tails is on the judge currently 20:25:45 <zzz> उनके पास tails i2p उपयोग का कोई विज़िबिलिटी नहीं है और कोई शोर भी नहीं सुनते, तो उन्हें यह झंझट ज़्यादा लगता है जितना लाभ 20:26:18 <eche|on> yeas 20:26:33 <zzz> आम तौर पर addressbook subscription प्रोटोकॉल जैसे बड़े फीचर के लिए, मैं इसे _पिछले_ रिलीज़ से एक हफ्ता पहले कर चुका होता, prop के लिए तैयार 20:26:54 <zzz> तो हम 3 हफ्ते पीछे हैं, साथ ही dev समय जो कम-से-कम कुछ हफ्ते है, यानी कुल 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> मुझे अब भी लगता है कि वहाँ दी गई क्रम में चीज़ें होनी चाहिए, तो हम जो कर सकते हैं वह यह कि address subscription प्रोटोकॉल को 0.9.27 तक पुश कर दें 20:29:27 <str4d> इससे आपको मई में उस पर काम करने का समय मिलेगा 20:29:47 <zzz> लेकिन अभी .26 है ही नहीं। कुछ हुआ ही नहीं। उसमें deb बदलावों के अलावा कुछ नहीं है 20:29:50 <str4d> और फिर .26 में CRLs और कुछ सामान्य क्लीनअप हो सकते हैं 20:30:08 <zzz> जब तक कोई (मुझे शामिल करके) कुछ नहीं करता, रिलीज़ के लिए कुछ नहीं है 20:30:27 <zzz> तो देखते हैं कैसे चलता है। मुझे अपने टैक्स करने के लिए भी कुछ दिन छुट्टी लेनी होगी :) 20:30:37 <zzz> 3a) शेड्यूल पर कुछ और? 20:30:55 <eche|on> योजनाबद्ध शेड्यूल पर बहुत सख्ती से मत देखो 20:30:56 <str4d> मेरे पास कुछ शुरुआती UI सुधार हैं जो मेरी और sadie की चर्चाओं से निकले हैं जिन्हें मैं अप्लाई कर सकता हूँ 20:31:20 <zzz> 3b) GMP 6 20:31:25 <str4d> (वह बड़ा री-डिज़ाइन नहीं जो मैंने प्लान किया है लेकिन कुछ सामान्य सुधार) 20:31:50 <zzz> लगभग 15 महीनों के काम के बाद, tuna और मैं 26 के लिए gmp6 ब्रांच को ट्रंक में prop करने के लिए लगभग तैयार हैं 20:32:05 <zzz> tuna ने पिछले 6 महीनों में लगभग सौ बाइनरी बनाए हैं, चेक-इन के लिए प्रतीक्षारत 20:32:25 <zzz> विभिन्न तरीकों से बने - VMs, नेटिव, 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 में निवेश करना चाहिए जिसे हम कहीं buildslave के रूप में चलने के लिए छोड़ सकें 20:39:44 <hottuna> eche|on: रीबिल्ड के बारे में: असंभव नहीं, लेकिन अभी मेरे लिए बहुत ज़्यादा काम है। बहुत ज़्यादा। 20:40:02 <str4d> बहुत महंगा नहीं, पर कुछ ऐसा जिसे हम वास्तव में तिकड़ी पूरी करने के लिए उपयोग कर सकें (मेरे VM वाले काम के बाद हमारे पास linux और windows buildslaves पहले से होंगे, एक बार जब मैं eche के साथ VM चीज़ें सुलझा लूँ) 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> बाइनरी स्वीकार करने के knock-on प्रभाव क्या हैं? 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> 'knock-on effect' = बुरी चीज़ें? 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 का पॉइंट यह है कि वैसे भी कुछ भी reproducible नहीं है। सब उधार के सिस्टम और बहुत पहले जा चुकी VMs 20:52:23 <zzz> eche|on, क्या उस बॉक्स का सिस्टम और msvc की जानकारी उपलब्ध है जिसका hottuna ने win बिल्डों के लिए उपयोग किया था? 20:53:10 <zzz> tuna ने किसी रिसर्च के लिए स्वयंसेवा नहीं किया लेकिन क्या उसने sadie का लैपटॉप भी उधार नहीं लिया? या क्या यह सब बेकार है क्योंकि इस बीच अपग्रेड्स हो चुके होंगे? 20:53:24 <eche|on> उसे मेरे kvm होस्ट पर win 10 मशीन की एक्सेस थी। मैं लॉगिन कर सकता हूँ और जाँच सकता हूँ 20:53:33 <str4d> म्म्म, यही कारण है कि मैं Buildbot में 6.1 बिल्ड करना चाहता हूँ उन buildservers के साथ जिन्हें हम ट्रैक कर सकें। 20:53:57 <hottuna> zzz: मैंने दो अलग-अलग दोस्तों की osx मशीनें उधार ली थीं 20:53:58 <eche|on> मैंने vm में कोई बदलाव नहीं किया 20:54:33 <zzz> कोई भी तो मुफ्त mac लेने के लिए भी तैयार नहीं है जिसका पैसा हम दें, क्योंकि कोई 'mac guy' बनना नहीं चाहता 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: क्रॉस-कम्पाइल, linux होस्ट्स। Compiler: GCC 20:56:03 <zzz> Linux: नेटिव बिल्ड। Compiler: GCC 20:56:03 <zzz> FreeBSD: नेटिव बिल्ड, VM। Compiler: GCC 20:56:03 <zzz> OSX: नेटिव बिल्ड। Compiler: GCC 20:56:03 <zzz> Build notes jcpuid: 20:56:03 <zzz> ------------------- 20:56:03 <zzz> Windows: नेटिव बिल्ड। Compiler: MSVC 20:56:03 <zzz> Linux: नेटिव बिल्ड। Compiler: GCC 20:56:03 <zzz> FreeBSD: नेटिव बिल्ड। Compiler: GCC 20:56:03 <zzz> OSX: नेटिव बिल्ड। Compiler: GCC 20:56:17 <zzz> क्या ये पर्याप्त हैं या हम फिर से शुरू करें? 20:57:14 <str4d> यह देखते हुए कि हम साल के अंत तक 6.1 पर माइग्रेट करने जा रहे हैं, और इन बाइनरीज़ का उचित परीक्षण हुआ है, मैं हाँ कहने की ओर झुकता हूँ। 20:57:41 <zzz> कोई आपत्ति? 20:57:45 <eche|on> यह कम से कम एक शुरुआत है, लेकिन "Tor reproducible builds" के संदर्भ में यह कुछ नहीं। हम किस तरह के मानक चाहते हैं? 20:58:03 <hottuna> नहीं 20:58:34 <eche|on> मैं उन्हें नई इंस्टॉल्स में "temp" फ्लैग के साथ शामिल करना चाहूँगा। मुझे पता है यह कठिन काम है। 20:59:14 <zzz> मूलतः वर्तमान परीक्षण शून्य पर आ गया है। अधिक परीक्षण पाने का एकमात्र तरीका उन्हें ट्रंक में लाना, और एक रिलीज़ करना है। 20:59:17 <susbarbatus> इसके बीच में टपकने के लिए क्षमा करें; मेरे पास कई macs हैं, और 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 (NOT 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, मैं जो सेट अप करना चाहूँगा वह एक buildserver है, अगर आप यह कमिट कर सकें कि एक mac हमेशा चल रहा होगा और जब कुछ फेल हो तो सवाल/मदद के लिए उपलब्ध होंगे। सामान्यतः इसमें आपकी बहुत भागीदारी नहीं लगेगी, क्योंकि buildserver स्वतः नियंत्रित होगा :) 21:01:28 <zzz> मेरा मानना है hottuna का प्रस्ताव था कि v13 बिल्कुल वही है जिसे रिलीज़ किया जाना है, न उससे अधिक, न कम। 21:01:38 <zzz> अगर चाहो तो हम बैठक के बाद इसे फिर से रिव्यू कर सकते हैं 21:01:38 <str4d> या अगर हमेशा नहीं चल रहा, तो कम-से-कम buildserver कॉन्फ़िगरेशन में आसानी से शुरू किया जा सके 21:01:51 <hottuna> zzz: शानदार 21:01:54 <str4d> (buildmaster उन buildservers को हैंडल करेगा जो हमेशा ऑनलाइन नहीं रहते) 21:02:12 <zzz> buildserver की बात को फिलहाल टेबल करें और 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 से मुलाकात हुई। प्रस्ताव अब भी यह है कि वह पूरे दिन के लिए एक छोटा conf. रूम देगा, या तो HOPE से पहले वाले दिन या बाद वाले दिन 21:03:04 <zzz> यानी 21 या 25 जुलाई 21:03:22 <zzz> मैंने उस पर ज़ोर दिया कि हमें जल्दी ही तारीख और कमिटमेंट चाहिए, ताकि हम हवाई जहाज़ के टिकट खरीद सकें 21:03:46 <zzz> यह पब्लिक के लिए खुला नहीं होगा। सिर्फ आमंत्रण पर, 5-6 लोग, रोडमैप बैठकों आदि के लिए बस एक हैंगआउट 21:03:51 <str4d> इस चरण में मैं वहाँ होने के लिए कमिट नहीं कर सकता, भले ही थोड़ी संभावना है कि तब तक मैं US में हो सकता हूँ 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> (सब इस पर निर्भर करता है कि मेरा thesis डिफ़ेन्स कब बुलाया जाता है, अभी पता नहीं कब होगा) 21:06:09 <str4d> (और अन्य वीज़ा-संबंधी बातों पर भी) 21:06:17 <str4d> अगर मेरा thesis डिफ़ेन्स उससे पहले है, तो मैं वहाँ होना चाहूँगा (चाहे बस रास्ते में ही उड़ते हुए) 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: मेरे लिए समय के लिहाज़ से यह वास्तव में अटपटा है। मुझे 16 जुलाई को एक शादी के लिए EU में होना है। 21:07:15 <hottuna> मुझे नहीं लगता कि मैं अभी कमिट करने की हिम्मत करूँ। 21:07:20 <zzz> बढ़िया, वापसी में NYC से होकर आओ :) 21:07:26 <hottuna> (या बिल्कुल भी नहीं अगर अभी करना पड़ता है) 21:07:33 <hottuna> hmmph.. 21:07:44 <hottuna> बुरा विचार नहीं 21:07:47 <zzz> 5) 3 महीनों के बाद मासिक बैठकों और प्रोजेक्ट प्रबंधन की संक्षिप्त समीक्षा 21:07:59 <str4d> तो मुझे meetup के लिए "उम्मीद है" और 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) अधिक वन-ऑन-वन इनपुट चाहिए 21:12:30 <hottuna> zzz: यह किसी भी तरह से बढ़िया नहीं है, लेकिन "गहरी परेशानी" शायद बढ़ा-चढ़ाकर कहना है। 21:13:02 <str4d> zzz, मेरे केस में, मैंने sadie के साथ साप्ताहिक बैठकें सेट की हैं ताकि मुझे ट्रैक पर रखने में मदद मिले, और उसे मेरी I2P टूडू सूची की एक्सेस दी है ताकि वह प्राथमिकता तय करने में मदद कर सके 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> क्योंकि अगर उन्होंने पहले तीन हफ्तों में कुछ नहीं किया, तो संभावना नहीं कि आखिरी हफ्ते में कर लेंगे 21:17:21 <str4d> इसलिए मुझे लगता है कि जिन लोगों के पास पेंडिंग आइटम हैं उनके लिए और नियमित त्वरित चेकअप बेहतर हैं, जो मैं sadie के साथ आज़मा रहा हूँ 21:17:34 <zzz> इस बिंदु पर मुझे नहीं लगता कि मुझे comradenosebleed से ड्राफ्ट वापस मिलेगा, या कोई CoC, या वेब पर उपयोग के मामले, या कोई Android रिलीज़, कम-से-कम किसी विशेष तारीख तक तो नहीं, चाहे कितनी दूर की हो 21:18:10 <zzz> इसलिए मैं एक्शन आइटम्स की मासिक समीक्षा बंद करने का प्रस्ताव रखता हूँ। हमेशा की तरह, लोग ओपन सोर्स में जो चाहेंगे करेंगे या नहीं करेंगे, और यहाँ किसी को कुछ करने के लिए मनाना बहुत बहुत कठिन है। 21:18:36 <zzz> लोग वही करेंगे जो वे चाहते हैं, और मेरे पास जो गाजर-छड़ी के तरीके हैं, वे प्रभावी नहीं हैं 21:19:50 <str4d> मैं वोट देता हूँ कि हम मासिक बैठकें रखें, और उनका उपयोग अपनी प्राथमिकताएँ समायोजित करने के लिए करें जो पिछले महीने में हुआ उस पर आधारित (जैसे हमने अभी .26 के बारे में किया kytv के बाद) 21:20:56 <susbarbatus> अच्छा, वह बाउंटी सिस्टम अभी कैसा चल रहा है? जैसे यह भुगतान प्रोत्साहन के साथ एक अच्छा संक्षिप्त सार्वजनिक सूची है। लोग अब भी उसे देख रहे हैं? 21:20:59 <susbarbatus> मैं जो उल्लेख करना चाहता हूँ; टास्क के लिए माइक्रोपेमेंट्स के बारे में क्या ख्याल है। 21:21:03 <str4d> इस बीच अगर कोई कुछ करने के लिए सहमत होता है, तो उसे sadie को प्रगति के बारे में सूचित रखने के लिए भी सहमत होना चाहिए, या कम-से-कम sadie को एक कम्युनिकेशन चैनल देना चाहिए ताकि वह उन्हें चुटकी ले सके :P 21:21:21 <zzz> ठीक है तो मैं प्रोजेक्ट मैनेजर के रूप में हटने का प्रस्ताव रखता हूँ, जिसे किसी सिस्टम और व्यक्ति TBD द्वारा बदला जाएगा। हम मासिक बैठकें करेंगे लेकिन एक्शन आइटम्स की समीक्षा के बिना 21:21:54 <zzz> अगली बैठक मंगलवार, 3 मई को होगी 21:21:58 <zzz> 5) पर कुछ और 21:22:10 <zzz> इस बैठक के लिए कुछ और? 21:22:35 <str4d> मेरी ओर से नहीं 21:22:53 <zzz> धन्यवाद सभी को, आज लंबी बैठक रही 21:22:58 * zzz *bafs* बैठक समाप्त