नमस्ते दोस्तों, फिर से साप्ताहिक अपडेट का समय आ गया है

  • Index
  1. SSU की स्थिति 2) यूनिट परीक्षण की स्थिति 3) Kaffe की स्थिति 4) ???
    1. SSU status

SSU transport पर कुछ और प्रगति हुई है, और मेरा वर्तमान विचार यह है कि थोड़े और लाइव नेटवर्क परीक्षण के बाद हम इसे बिना ज्यादा देरी के 0.6 के रूप में परिनियोजित कर सकेंगे। पहला SSU रिलीज़ उन उपयोगकर्ताओं के लिए समर्थन शामिल नहीं करेगा जो अपने फ़ायरवॉल में पोर्ट नहीं खोल सकते या अपना NAT समायोजित नहीं कर सकते, लेकिन वह 0.6.1 में उपलब्ध कराया जाएगा। जब 0.6.1 जारी हो जाएगा, परीक्षण हो जाएगा, और बेहतरीन प्रदर्शन कर रहा होगा (उर्फ़ 0.6.1.42), तब हम 1.0 की ओर बढ़ेंगे।

मेरा निजी रुझान यह है कि जैसे-जैसे SSU ट्रांसपोर्ट रोल‑आउट होता है, हम TCP ट्रांसपोर्ट को पूरी तरह हटा दें, ताकि लोगों को दोनों सक्षम रखने की ज़रूरत न पड़े (TCP और UDP दोनों पोर्ट्स को फ़ॉरवर्ड करना) और कोडर्स को अनावश्यक कोड का रखरखाव भी न करना पड़े। क्या किसी की इस पर कोई प्रबल राय है?

    1. Unit test status

जैसा कि पिछले सप्ताह उल्लेख किया गया था, Comwiz आगे आया है और यूनिट टेस्ट बाउंटी के पहले चरण का दावा किया है (वाह Comwiz! बाउंटी के लिए फंडिंग करने के लिए duck और zab का भी धन्यवाद!). कोड CVS में कमिट कर दिया गया है और, आपकी स्थानीय सेटअप के आधार पर, आप i2p/core/java डायरेक्टरी में जाकर “ant test junit.report” चलाकर (लगभग एक घंटे प्रतीक्षा करें…) junit और clover रिपोर्ट उत्पन्न कर सकते हैं, और i2p/reports/core/html/junit/index.html देख सकते हैं। दूसरी ओर, आप “ant useclover test junit.report clover.report” चला सकते हैं और i2p/reports/core/html/clover/index.html देख सकते हैं।

दोनों परीक्षण सेटों की एक कमी उस मूर्खतापूर्ण अवधारणा से जुड़ी है जिसे शासक वर्ग “copyright law” कहता है। Clover एक वाणिज्यिक उत्पाद है, हालांकि cenqua के लोग ओपन सोर्स डेवलपर्स को इसका निःशुल्क उपयोग करने की अनुमति देते हैं (और उन्होंने कृपापूर्वक हमें एक लाइसेंस देने पर सहमति जताई है)। Clover रिपोर्टें तैयार करने के लिए, आपके पास Clover स्थानीय रूप से इंस्टॉल होना चाहिए - मेरे पास clover.jar ~/.ant/lib/ में है, मेरी लाइसेंस फ़ाइल के बगल में। अधिकांश लोगों को Clover की आवश्यकता नहीं पड़ेगी, और चूँकि हम रिपोर्टें वेब पर प्रकाशित करने वाले हैं, इसे इंस्टॉल न करने से कार्यक्षमता में कोई कमी नहीं आएगी।

दूसरी ओर, जब हम स्वयं यूनिट टेस्ट फ्रेमवर्क पर विचार करते हैं, तो कॉपीराइट कानून का दूसरा पहलू हमें प्रभावित कर रहा है - junit IBM Common Public License 1.0 के अंतर्गत जारी किया गया है, जो FSF [1] के अनुसार GPL के साथ संगत नहीं है। अब, भले ही हमारे पास स्वयं कोई GPL कोड नहीं है (कम से कम core या router में तो नहीं), हमारी लाइसेंस नीति [2] पर नज़र डालें तो चीज़ों को कैसे लाइसेंस किया जाए, इसके विवरण में हमारा उद्देश्य यह है कि जितने अधिक से अधिक लोग संभव हो, वे बनाई जा रही चीज़ों का उपयोग कर सकें, क्योंकि गुमनामी भीड़ के साथ बेहतर काम करती है।

[1] http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses [2] http://www.i2p.net/licenses

चूँकि कुछ लोग बिना स्पष्ट कारण के GPL के तहत सॉफ़्टवेयर जारी करते हैं, इसलिए हमारे लिए यह उचित है कि हम प्रयास करें कि वे I2P का उपयोग बिना किसी प्रतिबंध के कर सकें। कम से कम, इसका मतलब यह है कि हम उस वास्तविक कार्यक्षमता को, जिसे हम उपलब्ध कराते हैं, CPL-लाइसेंस प्राप्त कोड (उदा. junit.framework.*) पर निर्भर नहीं होने दे सकते। मैं इसे यूनिट परीक्षणों को भी शामिल करने तक विस्तारित करना चाहूँगा, लेकिन junit परीक्षण फ़्रेमवर्कों की एक तरह की साझा भाषा प्रतीत होता है (और हमारे संसाधनों को देखते हुए, मुझे नहीं लगता कि “अरे, चलो अपना खुद का पब्लिक डोमेन यूनिट टेस्ट फ़्रेमवर्क बनाते हैं!” कहना जरा भी समझदारी होगी)।

इन सबके मद्देनज़र, मेरा विचार यह है: हम junit.jar को CVS में शामिल करेंगे और जब लोग यूनिट टेस्ट चलाएँगे तो उसका उपयोग करेंगे, पर यूनिट टेस्ट स्वयं i2p.jar या router.jar का हिस्सा बनकर नहीं बनाए जाएँगे और रिलीज़ में शामिल करके वितरित नहीं किए जाएँगे। आवश्यकता पड़ने पर हम अतिरिक्त JAR फ़ाइलों का एक सेट (i2p-test.jar और router-test.jar) उपलब्ध करा सकते हैं, लेकिन वे GPL के अंतर्गत लाइसेंस प्राप्त एप्लिकेशनों द्वारा उपयोग योग्य नहीं होंगी (क्योंकि वे junit पर निर्भर हैं)।

=jr