مرحباً يا جماعة، حان وقت التحديث الأسبوعي من جديد

  • Index
  1. حالة SSU 2) حالة اختبار الوحدة 3) حالة Kaffe 4) ???
    1. SSU status

لقد تحقق مزيد من التقدم في طبقة النقل SSU، وتصوري الحالي هو أنه بعد مزيد من الاختبارات على الشبكة الحية، سنتمكن من إطلاق الإصدار 0.6 دون تأخير كبير. لن يتضمن الإصدار الأول من SSU دعماً لمن لا يستطيعون فتح منفذ في جدار الحماية لديهم أو ضبط إعدادات NAT (ترجمة عناوين الشبكة)، لكن سيُطرح ذلك في 0.6.1. بعد صدور 0.6.1 واختباره والتأكد من أدائه الممتاز (المعروف أيضاً باسم 0.6.1.42)، سننتقل إلى 1.0.

أميل شخصياً إلى التخلي تماماً عن نقل TCP مع طرح نقل SSU، حتى لا يضطر المستخدمون إلى تفعيل الاثنين معاً (إعادة توجيه منافذ TCP وUDP معاً)، وحتى لا يضطر المبرمجون إلى صيانة كود غير ضروري. هل لدى أحدكم آراء قوية بشأن ذلك؟

    1. Unit test status

كما ذُكر في الأسبوع الماضي، تقدّم Comwiz للمطالبة بالمرحلة الأولى من مكافأة اختبارات الوحدة (مرحى Comwiz! شكراً لـ duck و zab على تمويل المكافأة أيضاً!). تم إيداع الشفرة في CVS، وحسب إعدادك المحلي، قد تتمكن من توليد تقارير junit و clover بالانتقال إلى الدليل i2p/core/java وتشغيل “ant test junit.report” (انتظر نحو ساعة…) ثم عرض i2p/reports/core/html/junit/index.html. ومن ناحية أخرى، يمكنك تشغيل “ant useclover test junit.report clover.report” ثم عرض i2p/reports/core/html/clover/index.html.

الجانب السلبي في مجموعتي الاختبارات كلتيهما يتعلق بذلك المفهوم السخيف الذي تسميه الطبقة الحاكمة “قانون حقوق الطبع والنشر”. Clover منتج تجاري، إلا أن الفريق لدى cenqua يسمح باستخدامه مجانًا من قبل مطوري البرمجيات مفتوحة المصدر (وقد تكرموا ووافقوا على منحنا ترخيصًا). لإنشاء تقارير Clover، تحتاج إلى تثبيت Clover محليًا - لدي clover.jar في ~/.ant/lib/، بجوار ملف الترخيص الخاص بي. معظم الناس لن يحتاجوا إلى Clover، وبما أننا سننشر التقارير على الويب، فلا يوجد فقدان في الوظائف بعدم تثبيته.

من ناحية أخرى، نحن نتعرّض للجانب الآخر من قانون حقوق النشر عندما نأخذ إطار اختبارات الوحدات نفسه في الاعتبار - إذ إن junit موزَّع بموجب رخصة IBM Common Public License 1.0، والتي، بحسب FSF [1]، ليست متوافقة مع GPL. الآن، ورغم أننا لا نملك أي شيفرة GPL بأنفسنا (على الأقل ليس في النواة أو في 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