لینک کوتاه مطلب : https://hsgar.com/?p=6119

گنوم در 25: یک بررسی سلامت

در حدود پایان سال 2020، من به تاریخچه تعهد گنوم به عنوان یک پروکسی برای سلامت کلی پروژه نگاه کردم. انجام آن سرگرم کننده بود و امیدوارم خواندن آن خیلی خسته کننده نباشد. یک سال و نیم از آن زمان می گذرد و زمان به روز رسانی فرا رسیده است.

اگر به طور متوسط ​​​​این شادی را می بینیدویفالا نمودارها برای اولین بار، پست قبلی کارش را بهتر توضیح می دهد. به خصوص بخش روش شناسی. ارزش یک سرکشی سریع را دارد.

چه خبر

  • فورنالدر توانایی تخصیص گروه ها بر اساس پسوند فایل، پیشوند مسیر و مخزن را به دست آورد.
  • نویسندگان تکراری بیشتری را فیلتر می کند.
  • همچنین در فیلتر کردن موارد تکراری و در غیر این صورت جعلی بهتر شد.
  • من مخازن پیشنهادی آلن و فدریکو را در آن اضافه کردم این مشکل GitHub (تفاوت).
  • مدتی گذشت.

مشارکت کنندگان فعال، بر اساس نسل

همانطور که انتظار می رفت، سال 2020 جالب بود. مشارکت کنندگان برای اولین بار در دروازه حضور داشتند و تعداد آنها حدود 200 نفر بیشتر از سال های گذشته بود. آنچه نیز واضح است این است که آنها عمدتاً به اطراف نمی چسبیدند. داده ها چیزی در مورد دلیل این امر نمی گویند، اما می توانید حدس بزنید که یک رژیم کار از خانه و به دنبال آن یک رژیم جامد اقامت وضعیتی است که در نهایت منجر به ایجاد خارش مماس – و محدود – با مضمون نرم‌افزاری می‌شود، و به نظر شما بسیار معقول است. کارکنان اداری زمان و انعطاف پذیری بیشتری در محل کار داشتند تا به سؤالات مهم زندگی فکر کنند، مانند “چرا دوچرخه من رنگ بژ اشتباهی می اندازد” یا شاید “این تعهدات چطور است”. همانطور که یکی انجام می دهد.

همچنین می‌توانید استدلال کنید که گنوم در ادغام درخواست‌های کششی بهتر عمل می‌کند، و این نیز منطقی به نظر می‌رسد. علت هرچه که باشد، افراد بیشتری انگشتان پای خود را فرو می‌کنند و این بی‌تردید خوب است. چگونه بهبود یابد؟ با طناب زدن آنها را به انجام کار حتی بیشتر! و هرگز آنها را رها نکنید.

2021 موارد مشابه بیشتری را به ارمغان آورد. بالاتر از خط پایه 2019، 200 مشارکت‌کننده جدید دیگر ظاهر شدند، وصله‌ها را رها کردند و برگشتند.

مشارکت کنندگان فعال، بر اساس وابستگی

برخلاف دفعه قبل، من وابستگی های شخصی و دیگر را برای این یکی گنجانده ام، زیرا مشارکت های شرکتی را در چشم انداز قرار می دهد. گنوم یک پروژه متنوع و کم تلفیقی با طولانی و مبهم است دم. از نظر میزان گستردگی پایگاه مشارکت‌کننده در دامنه‌های مختلف، حتی بالاتر از سایر پروژه‌های انجمن واقعی مانند گنو و هسته لینوکس قرار دارد.

تعداد تعهد، بر اساس وابستگی

اگر منصف باشیم، حجم مشارکت ها مهم است. توسعه‌دهندگان پولی بسیار بالاتر از تعدادشان هستند، و همانطور که قبلاً دیده‌ایم، Red Hat بیشتر از هر کسی مشت می‌زند. مطمئناً این برای همیشه ادامه خواهد داشت (خنده عصبی).

ایزل آخرین بار به سختی موفق به برش بالای 15 شدم. اکنون از لیست خارج شده است. این همان چیزی است که برای فشار دادن ابر، یک دهه کامل جلوتر از زمان خود، به دست می آورید.

مشارکت کنندگان فعال، بر اساس مخزن

برش داده ها در هر مخزن، مشاهدات جالبی را ایجاد می کند:

  • صحبت از Eazel … Nautilus ممکن است تا حدودی به خاطر آنچه هست ضعیف باشد، اما بدتر دیده می شود. فروپاشی 2005-2007 بود بد. با توجه به این موضوع، تلاش برای کاهش پیچیدگی (ر.ک. در نهایت حذف نمای فشرده و غیره) منطقی است. شاید در یک لحظه بی سر و صدا دندان قروچه کرده باشم، اما این روزها استفاده از ناتیلوس برای کارهای کوچک بسیار لذت بخش است. و برای Big Work، ترمینال خود، پوسته دوستانه و GNU Coreutils را دارید. الان و برای همیشه.
  • با تایید آنچه “همه می دانند”، حفظ تکامل در طول دهه 2010 کاهش یافت تا جایی که فقط میلان کرها قهرمانانه باقی ماند. برای آن دسته از ما که مدت طولانی و عمیق از کول کمک می نوشیم، این چیزی است که باید نسبت به آن احساس ترس (و تا حدودی گناه) کنیم.
  • والا نقش جالبی در انقلاب زیرساخت GNOME در سال‌های 2009-2011 ایفا کرد. سپس به نوعی… از بین رفت؟ مطمئناً، Rust در حال حاضر داغ است، اما من فکر نمی کنم که بتواند آن را بخورد کل ناهار.
  • GLib به طور جدی به خوبی نگهداری می شود!

تعداد تعهدات، بر اساس مخزن

با شمارش commit، چند چیز ظاهر می شود که قبلاً قابل مشاهده نبودند:

  • یک ردیاب که اصلاً نامش آشکار نیست وجود دارد، یادآوری دیگری از اینکه چارچوب زمانی 2009-2011 واقعاً چقدر متحول بود.
  • اواسط دهه 2010 در بیشتر نمودارها به نوعی بی‌حادثه و ملایم به نظر می‌رسد، اما سازنده این روند را تا حد زیادی شکست داد.
  • به کاهش بزرگ تعهدات از 2020 تا 2021 توجه کنید؟ این بیشتر فقط تیم GTK+ است که پس از انتشار نسخه 4.0 (احتمالاً) باز می شود.

مشارکت کنندگان فعال، بر اساس پسوند فایل

من این یکی را عمدتا برای پرداختن به نظری از Smeagain طراحی کردم. این یک نگرانی معتبر است:

افراد زیادی در حال ترجمه هستند که هر کدام یک تعهد برای هر ترجمه ای دریافت می کنند. در طول سال، تکه‌های بزرگ‌تری از متن برای ترجمه دریافت می‌کنید، سپس اندکی قبل از انتشار، کارهای کوچک‌تری را به پایان می‌رسانید، ترجمه‌ها را تمیز می‌کنید و در نهایت با تعهدات زیادی برای کارهای زیادی مواجه می‌شوید، اما این کد نیست. به جز تخفیف ترجمه، شما تعهدات بسیار کوچک زیادی دارید.

من اگنوستیک محتوا را یک ویژگی می‌دانم: ما نمی‌توانیم تفاوت سرمایه‌گذاری در کار را بین دو تعهد کد تشخیص دهیم (شاید یک خط یک خطی با یک هفته تجزیه و تحلیل در پشت آن در مقابل یک تکه بزرگ از دیگ بخار که از ماژول دیگری کپی شده است. /snippet database)، پس چرا باید در مورد ترجمه ها فرضیاتی داشته باشیم؟ شاید مترجم یک ساعت صرف بررسی رشته‌های آن‌ها کرد، چند مورد مشکوک را پیدا کرد، فرهنگ لغت آنها را شکست، با یکی از دوستانش تماس گرفت تا در مورد بهترین عملکرد توصیه کند و در نهایت یک تفاوت یک خطی پیدا کرد.

بنابراین ما نوع محتوا foo را مانند نوار نوع محتوا، تعهدات بزرگ مانند تعهدات کوچک، و هنگام جمع‌آوری نویسندگان، تعداد کمی از نویسندگان به اندازه تعداد زیادی انجام می‌شوند – تا زمانی که حداقل یک commit در بازه زمانی (سال یا ماه) داشته باشید. ، شما حساب می شوید.

با این حال! اگر به گزارش های commit نگاه کنید (و زیرساخت های مربوطه، کاملاً واضح است که هکرها و مترجمان به عنوان دو گروه مجزا عمل می کنند. و شاید گروه های بیشتری وجود داشته باشد که ما از آنها بی اطلاعیم، یا ماهیت کار با گذشت زمان تغییر کرده است. بنابراین ما آن را بر اساس نوع محتوا، یا بهتر است بگوییم، پسوند فایل (نه به خوبی، اما بسیار آسان تر). برای فایل‌های بدون جداکننده پسوند، پسوند کل نام فایل است (مثلاً Makefile).

یک نکته ظریف: از آنجایی که هر commit می تواند چندین نوع فایل را لمس کند، ما باید تصمیم بگیریم که در مورد 10 چه کاری انجام دهیم. .c فایل ها و 2 .py فایل ها. با استفاده از اصل اگنوستیسیسم فوق، آن را به عنوان انجام کاری با این دو نوع فایل شناسایی می کنیم و وزن برابر به آنها اختصاص می دهیم، که منجر به 0.5 می شود. c متعهد می شود و .5 py متعهد می شود. این امر به نویسندگان منتشر می‌شود، بنابراین اگر در سال 2021 شما تعهد فوق‌الذکر را انجام دهید به‌علاوه یکی دیگر کاملاً vala، شما به عنوان 0.5 محاسبه می شود c + .5 py + 1.0 vala، و پس از عادی سازی شما یک ¼ خواهید بود c، ¼ py و ½ vala نویسنده آن سال این کامل نیست (به آنچه که با هم متعهد می شود حساس است)، اما تعهدات کافی وجود دارد که آن را یکسان می کند.

به هر حال. از نمودار حاصل چه می توانیم بگوییم؟

  • قبل از Git، متادیتای commit درون باند نگهداری می شد. این بدان معناست که شما باید پیام گزارش را دو بار (ابتدا در ChangeLog و سپس به عنوان متاداده CVS commit) قرار دهید. با توجه به اینکه همه دائماً به ChangeLogs متعهد می شوند، به طور طبیعی (اما به اشتباه) به عنوان یک نقطه کانونی قبلی برای پروژه خوانده می شود. خوشحالم که تمام شد.
  • گنوم یک پروژه C بوده و هست. علیرغم همه نوع غوغاها، موقعیت آن در 25 سال به سختی جابجا شده است.
  • با این حال، Autotools مورد حمله قرار گرفت و با موفقیت از سلطنت خلع شد. بین 2017 و 2021، ac و am به تدریج به مزون تسلیم شد build.
  • در نهایت مترجمان (po) در واقع بخش بزرگی از جامعه را تشکیل می دهند. در اینجا یک شگفتی مدفون وجود دارد: در مقایسه سال های 2010 با 2021، این گروه بسیار کوچک شد. از آنجایی که ترجمه‌ها هرگز «انجام نمی‌شوند» – در واقع، برای بیشتر زبان‌ها در وضعیتی همیشگی قرار دارند که نسبتاً از آن دور هستند – کمی نگران‌کننده است.

تصویر بزرگتر

من به مشاهدات زیرکانه فیلیپ توجه کردم:

اگر کمی بیشتر به این موضوع فکر کنید، اگر اوج را در سال 2010 کاهش دهید، همه معیارها تعداد نسبتاً ثابتی از مشارکت کنندگان، تعهدات و غیره را از سال 2008 تا کنون نشان می دهند. شاید تفسیر نباید این باشد که گنوم از سال 2010 در حال کاهش بوده است، بلکه بیشتر باید این باشد که اوج آن در حدود سال 2010 دور از ذهن بوده است.

برخی از پروژه های بزرگ F/OSS دارای مسیرهایی هستند که با الگوی زیر مطابقت دارند:

f (x) = ∑ [n = 1:x] (R * (1 – a)(n – 1))

یعنی هر سال R مشارکت کنندگان جدید در حال جذب هستند، در حالی که کسری a مشارکت کنندگان موجود ترک می کنند. R و a هر دو نسبتاً ثابت هستند، اما از آنجایی که فرسایش با اندازه پروژه افزایش می‌یابد در حالی که استخدام به عوامل خارجی بستگی دارد، آنها تمایل دارند تعادلی پیدا کنند که در آن یکدیگر را خنثی کنند.

برای GNOME، می توانید به عنوان مثال انتخاب کنید R = 130 و a = .15، و شما نزدیک می شوید. سپس تنها چیزی که نیاز دارید، جادوی تیز و…

#تیز تیز

تناسب بدی نیست خوشحال 25، گنوم.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.