I2P डेवलपर बैठक - 06 फ़रवरी, 2007

15:02 <jrandom> 0) हाय 15:02 <jrandom> 1) नेट स्थिति 15:02 <jrandom> 2) Syndie विकास स्थिति 15:02 <jrandom> 3) जनवरी बग हार्वेस्टिंग प्रतियोगिता के विजेता! 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> जहाँ तक मैं देखता हूँ, पैटर्न high powered router की क्षमता से जुड़े रहे हैं, पर वह नेटवर्क का बहुत सीमित दृष्टिकोण देता है (क्योंकि मुझे लगभग केवल वही पता है जो सार्वजनिक रूप से उपलब्ध है) 15:07 <tethrage> समझ गया 15:08 <tethrage> क्या कोई जानकारी दी जा सकती है जिससे मदद हो? 15:08 <tethrage> सामान्य router से, यानी 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: एक फ़ोरम ही एक पहचान है :) 15:16 <+void> और उल्टा भी 15:17 <jrandom> हाँ, हालांकि हम इस अजीब दोहरापन (duality) को बहुत स्पष्ट करके लोगों को ज़्यादा भ्रमित नहीं करना चाहते 15:17 <+fox> <mk> मुझे पता है, लेकिन फिर भी धुंधलापन है। अब तो मुझे यह ठीक से समझ में आता है, पर मुझे चिंता है कि नए उपयोगकर्ता भेद की कमी से भ्रमित हो सकते हैं 15:18 <+void> आह 15:18 <jrandom> सही - लोग फ़ोरम के बारे में identities के मुकाबले अलग तरह से सोचते हैं, तो हमें सुनिश्चित करना होगा कि हम अपेक्षित रूप से व्यवहार करें 15:18 <+fox> <mk> एक और चीज़ जो फ़ोरम या identity मैनेजमेंट में जोड़ने लायक हो सकती है वह है स्पष्ट 'post to this forum only under author x authorization y', जिससे गड़बड़ियाँ खत्म हो जाएँ। नए पोस्ट संदेशों पर आपको ड्रॉपडाउन की ज़रूरत भी नहीं पड़ेगी 15:19 <+fox> <mk> (keys के लिए एक ड्रॉपडाउन) 15:20 <+void> मैं एक global identity ड्रॉपडाउन पसंद करूँगा जो हर समय दिखे 15:20 <+fox> <mk> यानी, आप किस पहचान से पोस्ट कर रहे हैं? 15:20 <jrandom> हम्म 15:21 <+fox> <mk> शायद, लेकिन मुझे लगता है कि इसे हमेशा ऊपर रखने और सिर्फ़ पोस्ट पर दिखाने में बहुत अंतर नहीं है 15:22 <jrandom> ठीक है, इसमें बहुत गहराई में जाने से पहले, syndie में अभी एक साइड चैनल का समाधान नहीं है जो कई identities को लिंक कर सकता है 15:22 <+void> हालांकि आपकी identity पोस्टिंग के अलावा कहीं और प्रयोग नहीं होती 15:22 <+fox> <mk> आपका क्या मतलब है? 15:23 <+void> नए पोस्ट push करना? 15:23 <jrandom> अगर आपको पूरी तरह unlinkable identities चाहिए, तो आपको अलग-अलग syndie instances चलाने होंगे - आप उन्हें एक-दूसरे से sync कर सकते हैं, और केवल एक का उपयोग दूसरे archives से pull/push करने के लिए कर सकते हैं, लेकिन स्थानीय archive में वह जानकारी होती है जिस तक केवल कुछ identities की पहुँच होती है 15:23 <+fox> <mk> (मैं सहमत हूँ कि बड़ी चर्चाएँ dev फ़ोरम के लिए बचानी चाहिए, लेकिन एक साथ कई लोग इस पर बात करें तो अच्छा है) 15:24 <+void> सही 15:24 <jrandom> हालांकि, स्थानीय archive पर सभी identities उस जानकारी तक पहुँच सकती हैं, और अगर वे उस पर कार्रवाई करती हैं (उन्हीं keys से पोस्ट करके, आदि), तो उनकी linkability लीक हो जाएगी 15:25 <jrandom> शायद हम GUI के ज़रिए यह सब पारदर्शी ढंग से कराने का तरीका ढूँढ सकें 15:26 <jrandom> (syndie को दो बार चलाए बिना स्थानीय रूप से अनेक archives के साथ चलाना) 15:26 <+fox> <mk> और भी कई मुद्दे हैं - जैसे कुछ archives को एक-दूसरे के विरुद्ध exclusive चिह्नित करना - जो गुमनामी में मदद कर सकते हैं। हमें इन सभी परिदृश्यों को परिभाषित करने की कोशिश करनी चाहिए और उनसे बेहद उपयोगी तरीके से निपटने का तरीका निकालना चाहिए 15:27 <tethrage> syndie का लक्ष्य गुमनामी नहीं, सिर्फ़ सुरक्षा है 15:27 <tethrage> यह काम तो जिस transport layer पर यह चलता है, उसे करना चाहिए, है न? :/ 15:27 <jrandom> syndie का लक्ष्य गुमनामी है 15:27 <tethrage> (यदि मैं गलत हूँ तो सुधारें) 15:28 <jrandom> transport layer गुमनामी के केवल छोटे हिस्से से निपटती है - बाकी से हमें निपटना होगा 15:28 <jrandom> s/small// 15:28 <tethrage> क्या वाकई? :/ 15:28 <+fox> <mk> हाँ, सही। syndie विशेष रूप से information leaks से निपटता है 15:29 <jadeSerpent> ip address anonymity बनाम identity anonymity 15:29 <tethrage> समझ गया। मुझे लगा था आपने पहले कहा था कि syndie एक सुरक्षित ऐप है जो crypto का उपयोग करता है, पर सख्ती से अनाम नहीं है? 15:29 <tethrage> (कम से कम i2p आदि की तरह नहीं) 15:29 <+fox> <mk> सूचना सुरक्षा archives की अतिरिक्त प्रतियों (redundancy) से संभाली जाती है 15:29 <jrandom> mk: मुझे समझ नहीं आ रहा कि आप archives को मार्क करने से क्या मतलब ले रहे हैं, पर इस पर syndie dev फ़ोरम में एक पोस्ट अच्छा रहेगा :) 15:29 <jrandom> tethra: syndie का उपयोग उन चीज़ों के लिए भी किया जा सकता है जिन्हें गुमनामी की ज़रूरत नहीं है 15:30 <jrandom> पर syndie उन चीज़ों के लिए उपयोगी होना चाहिए जिन्हें गुमनामी चाहिए 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> निश्चित रूप से, जब तक अलग से न कहा जाए, आप archives को सीधे ही एक्सेस करते हैं, आदि? 15:32 <+fox> <mk> tethrage, हर तरह के सूचना-रिसाव। चाहें तो थोड़ी देर में विस्तार से बात कर सकते हैं 15:33 <jrandom> tethra: उदाहरण के लिए, कोई eepsite को javascript सक्षम करके एक्सेस कर रहा हो 15:33 <jadeSerpent> tethrage: कोई गारंटी नहीं कि जो पोस्ट आप किसी archive में push करते हैं, वे आप ही से आई हैं; कोई और भी उन्हें आपके archive में push कर सकता है 15:34 <tethrage> jrandom: हाँ, JS चीज़ें लीक कर सकता है वगैरह। पर अगर आप किसी अनाम नेटवर्क का इस्तेमाल नहीं कर रहे, तो वह अधिकतर सुरक्षा का मामला है, गुमनामी का नहीं, है न? 15:34 <tethrage> खैर, शायद मैं बस शब्दार्थ पर बहस कर रहा हूँ, तो मैं रुकता हूँ 15:34 <tethrage> :/ 15:34 <jadeSerpent> मैं कहूँगा कि अपना सार्वजनिक रूप से उपलब्ध archive चलाना उस संदर्भ में आपकी गुमनामी बढ़ाता है 15:34 <+fox> <mk> jrandom, मैं वह पोस्ट करूँगा। साथ ही, मैं एक ब्राउज़र के डिज़ाइन से खेल रहा था (मुझे नए सेक्शनों के लिए नए टैब खोलना पसंद नहीं), तो मैं उसका एक प्रोटोटाइप बनाने की कोशिश करूँगा, और शायद dev पर कुछ स्केच पोस्ट कर दूँ 15:34 <jrandom> "security against information leaks" गुमनामी का मूल है - यह नियंत्रित करना कि आपकी पहचान के बारे में तथ्य कौन जानता है 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> हाँ। और अगर कुछ लोग tabbed-for-all तरीका पसंद करते हैं, तो वह भी ठीक है 15:38 <+fox> <mk> (ब्राउज़र टैब के साथ) 15:39 <jadeSerpent> कृपया mdi नहीं, मैं tabbed और mdi के बीच का कुछ सुझाव दूँगा, Eclipse की perspectives 15:39 <+void> mdi बुरा है, मैं सहमत हूँ 15:40 <jadeSerpent> netbeans में भी वैसा कुछ है, भूल गया क्या कहते हैं 15:40 <jadeSerpent> views या workbenches या कुछ, काफी समय हो गया 15:41 <jrandom> .webp स्केच स्वागतयोग्य :) 15:41 * jrandom ने tab-for-all शैली इसलिए चुनी क्योंकि सबको firefox (/etc) पसंद है 15:42 <jadeSerpent> जब मैं आइकॉन खत्म कर लूँगा तो शायद उस पर कुछ hack करूँ 15:42 <+fox> <mk> 2 हफ्ते की रिलीज़ साइकिल अच्छी है। मुझे वे लक्ष्य स्पष्ट दिखना पसंद है, लेकिन मैं कुछ 'नरम' लक्ष्यों को भी सूचीबद्ध देखना चाहूँगा - dev और बाद में उपयोगकर्ता डाक्यूमेंटेशन, डायग्राम वगैरह 15:42 <jrandom> कमाल 15:42 <jadeSerpent> tabs अभी के लिए ठीक हैं imo, वे उपयोगी हैं 15:42 <jrandom> mk: http://syndie.i2p.net/roadmap.html ? 15:42 <jrandom> (हालाँकि रोडमैप पर तारीखें नहीं हैं) 15:43 <+fox> <hottuna> अच्छा :=) ... अभी इसके बारे में pending tasks में पोस्ट किया :P 15:44 <+fox> <mk> हाँ, लेकिन मैं छोटे लक्ष्यों की बात कर रहा हूँ। "document the general interactions between classes in syndie.gui", या "write up a doc regarding 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) जनवरी बग हार्वेस्टिंग प्रतियोगिता के विजेता! पर चलते हैं 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, the key, मेरा खयाल :) 15:52 <jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :) 15:53 <jrandom> हो सकता है पाँच लोग वह key साझा कर रहे हों 15:53 <jrandom> लेकिन फिर उन्हें $50USD बाँटना पड़ेगा ;) 15:53 <jrandom> (जो भी सबसे पहले private key के साथ मुझे एक संदेश sign करके भेजे कि किस egold acct में भेजना है, वही जीतेगा ;) 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 आइटम में से एक है - bugtracking पर एक वास्तविक मैनेजमेंट UI लाना 15:58 * jadeSerpent trac की सिफ़ारिश करता है 15:58 <jrandom> (मुझे सारे पोस्ट पढ़कर और उन्हें मैन्युअली गिनकर कुछ समय लगा) 15:58 <+fox> <mk> syndie के बाहर? 15:59 <jrandom> हम्म, एक syndie-->track exporting सिस्टम के साथ? 15:59 <jrandom> s/ck// 15:59 <+fox> <mk> एक अच्छा प्रोजेक्ट होगा syndie को किसी bug tracker से हुक करना 15:59 <jadeSerpent> हाँ 15:59 * jrandom शर्त लगाता है कि कुछ SQL queries & inserts से काम चल जाएगा 16:00 <jrandom> फिर भी यह काफ़ी उपयोगी होगा, कम से कम एक readonly-trac दृष्टिकोण से 16:00 <+void> लेकिन trac में किए गए अपडेट्स को वापस syndie में sync करना मुश्किल होगा, मेरा खयाल है 16:00 <jrandom> पूरे चक्र का एकीकरण बहुत कठिन है 16:00 <jrandom> सही 16:00 <+fox> <mk> किसी समय 'revision'-टाइप सिस्टम पर विचार करना उपयोगी हो सकता है 16:00 <jrandom> लेकिन trac में query करना, drill down करना, रिपोर्ट बनाना, आदि सक्षम होना 16:01 <+fox> <mk> जहाँ पोस्ट पुराने वाले को supercede करें 16:01 <jrandom> आह, हाँ उसके लिए hooks हैं, पर Overwrite* headers का अभी मान नहीं रखा जाता 16:02 <jrandom> बहुत कठिन नहीं होगा, बस UI में एक टॉगल जो उसी पोस्ट के पुराने revs पर नेविगेट करे, साथ में कुछ लाइन कोड जो सत्यापित करे कि पोस्ट पुराने पोस्ट को ओवरराइड करने के लिए अधिकृत है 16:03 <jadeSerpent> मैं समझता हूँ कि बग रिपोर्टिंग के लिए syndie का उपयोग करने की इच्छा है, पर इसका डिज़ाइन issue tracking शामिल नहीं करता, और उस काम के लिए यह हमेशा sub-optimal ही रहेगा; मेरी राय में आपको एक वास्तविक issue tracker का उपयोग करना चाहिए 16:04 <+fox> <mk> दायर किए गए बग्स की संख्या देखकर, मैं jadeSerpent से सहमत हूँ 16:05 <jrandom> हालांकि दूसरी तरफ़, कितने बग्स उन लोगों ने खोजे जो बग दर्ज करने के लिए syndie का उपयोग कर रहे थे? 16:05 * jrandom trac या किसी और bug tracking सिस्टम के ख़िलाफ़ पूरी तरह नहीं है 16:05 <jadeSerpent> वैसे भी उस तरह के बग्स तो खोजे ही जाने वाले थे 16:05 <+void> खैर, severities, components, versions और बग्स को बंद/खोलना/दोबारा खोलना syndie टैग्स से किया जा सकता है 16:05 <jrandom> सही 16:06 <+void> (और उन में से अधिकांश पहले से होते हैं) 16:06 <jadeSerpent> जैसे पिछले दिन जब कोई बग रिपोर्ट पोस्ट कर रहा था तब यह फ्रीज़ हो गया, अगर वे किसी भी विषय पर पोस्ट कर रहे होते, तो भी यह फ्रीज़ होता, इससे फ़र्क़ नहीं पड़ता कि वह बग रिपोर्ट थी 16:06 <jrandom> अगर हम एक वास्तविक issue tracker को छद्म नाम से (और प्रमाणिक) संदेशों के माध्यम से फीड कर सकें, तो बढ़िया होगा 16:06 * jrandom को कुछ निजी बग रिपोर्ट भी मिली हैं, जिनमें संवेदनशील जानकारी शामिल है - ये syndie की एन्क्रिप्शन से सुरक्षित हैं 16:07 <+fox> <mk> अच्छा, दोनों क्यों न रखें? 16:08 <jadeSerpent> मैं सहमत हूँ कि फिर भी कोई issue tracker ऐसा नहीं है जो गुमनामी या तुच्छ से अधिक गोपनीयता को ध्यान में रखकर डिज़ाइन किया गया हो 16:09 <+fox> <mk> अच्छा होगा अगर syndie में वैसा बग ट्रैकर हो, लेकिन अधिकांश बग रिपोर्ट दर्ज करते समय गुमनामी इतनी बड़ी समस्या नहीं है 16:10 <jadeSerpent> शायद trac को mod किया जा सके ताकि वह वहाँ syndie की विशेषताओं का उपयोग करे 16:10 <+fox> <mk> jade, यह कठिन होगा। ब्राउज़र्स signing लागू नहीं करते 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 बना रहे हैं, कोई bug tracker नहीं :) 16:14 <jadeSerpent> हाँ ठीक है, आप फिलहाल बिना उसके भी इसे मैनेज करते दिख रहे हैं ;) 16:14 <jrandom> पर मुझे यक़ीन है कि कुछ चीज़ें दरारों में गिर जाएँगी, और दूसरों के लिए यह पता लगाना कि क्या ज्ञात है/आदि, और सुधार देना, कठिन होगा 16:15 <+fox> <mk> शायद हमें इसे syndie के जरिए लागू करने की भी ज़रूरत नहीं। वहाँ यह कुछ हद तक उपयोगी है, लेकिन 200+ बग्स वाकई बहुत हैं। हमें एक ट्रैकर तय करना चाहिए और उसे www और i2p दोनों के ज़रिए उपलब्ध कराना चाहिए 16:16 <+fox> <mk> syndie की 'file a bug' स्क्रीन के ऊपर उसका लिंक दें, और इस तरह हमारे पास दोनों विकल्प होंगे। syndie में बग ट्रैकर लागू करना अभी संसाधन लगाने की चीज़ नहीं है 16:17 * jrandom को इंटीग्रेटेड बग ट्रैकिंग पसंद है (ताकि लोगों को बग ट्रैकिंग अकाउंट नहीं बनाने पड़ें, नकली ईमेल एड्रेस इस्तेमाल नहीं करने पड़ें, आदि), पर हमें कौन-सा समाधान इस्तेमाल करना चाहिए इस पर प्रस्तावों के लिए मैं खुला हूँ 16:17 <+fox> <mk> मुझे लगता है हमें वह रखना चाहिए, और साथ ही वह bug tracker भी होना चाहिए 16:18 <jadeSerpent> अल्पावधि के लिए read-only पहुँच अच्छी रहेगी 16:18 <jadeSerpent> मुझे अधिक बग-उन्मुख सर्च इंटरफ़ेस पसंद है 16:18 <jrandom> इतना भी बुरा नहीं होगा, शायद हम बिना ज़्यादा दिक्कत के एक one-way syndie-->issue tracker export लिख सकें, of r उनके लिए जो वेब आधारित वाला उपयोग नहीं कर सकते/नहीं करना चाहते 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 के लिए मैं 'blah' कहूँगा 16:22 <jrandom> हालांकि, एक बात और - अगर कोई किसी issue tracker से काफ़ी परिचित है, तो syndie-->issue tracker export निकालने में मदद मिलेगी 16:22 <jrandom> हाँ, bugzilla एक दैत्य है 16:22 <jadeSerpent> jira भी अच्छी है, trac जैसी 16:23 <+void> trac शायद बहुतों के लिए जाना-पहचाना भी है 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 रोडमैप पर है, iirc 16:26 <jrandom> कूल 16:26 <+fox> <modulus> यह तो उन लोगों के साथ होना ही है जो सन का कट्टर समर्थन करते हैं :-) 16:27 * jrandom modulus पर javabeans फेंकता है 16:27 <jadeSerpent> भले ही mylar आधिकारिक तौर पर Eclipse फाउंडेशन के अंतर्गत है 16:27 <+fox> * mk trac के लिए कोई live साइट नहीं ढूँढ पा रहा 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> (^ आधिकारिक meta-trac) 16:29 <+fox> <mk> हाँ, मुझे तो सब एक जैसा है 16:30 * jrandom मान लेगा कि * 3) जनवरी बग हार्वेस्टिंग प्रतियोगिता के विजेता! यहीं तक और हमें 4) ??? पर ले चलता है 16:30 <jrandom> बैठक के लिए किसी के पास और कुछ है? 16:30 <+fox> <mk> 'best' का बहुत हल्ला है। जिसके पास इन चीज़ों का सबसे ज़्यादा अनुभव है, वह शायद सिक्का उछाल दे 16:32 * jrandom दरअसल किसी प्रोजेक्ट प्लानिंग / रिलीज़ प्लानिंग सिस्टम, या सोर्स कोड ब्राउज़र की तलाश में नहीं है (एक मुक्त विकि बुरा नहीं, पर हमारे पास ugha.i2p भी है) 16:32 <jrandom> मेरे लिए वहाँ सिर्फ़ एक फीचर मायने रखता है - issues को ट्रैक करना 16:37 <jrandom> ठीक है, अगर बैठक के लिए और कुछ नहीं है... 16:37 * jrandom समेटता है 16:37 * void jrandom को baffer थमाता है 16:37 * jrandom *baf*s के साथ बैठक समाप्त करता है