Product SiteDocumentation Site

1.3. شیوه اجرایی داخلی در پروژه دبیان

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

1.3.1. توسعه‌دهندگان دبیان

توسعه‌دهندگان دبیان نقش‌های متفاوتی دارند، به عنوان اعضای رسمی پروژه، آن‌ها تاثیر مستقیمی بر جهت‌گیری آینده پروژه دارند. یک توسعه‌دهنده دبیان معمولا مسئول یک بسته خاص به حساب می‌آید، اما با توجه به زمان و اشتیاقی که از خود نشان می‌دهند، می‌توانند در پروژه‌های گوناگونی مشارکت داشته باشند که این امر به اخذ مسئولیت‌های بیشتر در پروژه منجر می‌شود.
نگهداری از بسته‌ها یک فعالیت به شدت کنترل‌شده به حساب می‌آید که مستندات و قوانین بسیاری را شامل می‌شود. این فرآیند، باید در حقیقت با تمام استانداردهای تدوین شده در خط‌مشی دبیان سازگاری داشته باشد. خوشبختانه، ابزار بسیاری وجود دارد که این فرآیند را تسهیل می‌بخشند. توسعه‌دهنده با استفاده از آن‌ها می‌تواند بر جنبه‌های خاصی از بسته تمرکز کند و کارهای پیچیده بیشتری انجام دهد، مانند مدیریت باگ‌ها.
خطی مشی، یک عنصر ضروری در پروژه دبیان، شامل هنجارهایی می‌شود که هم کیفیت بسته‌ها را شامل می‌شوند هم قابلیت همکاری افراد در کل توزیع. به لطف این خط‌مشی و به رغم حجم عظیم پروژه دبیان، سازگاری آن از بین نرفته است. این خط‌مشی در طول زمان متغیر است و چگونگی تغییر محتویات آن از طریق میلینگ لیست پیگیری می‌شود. اصلاحاتی که همگان روی آن توافق دارند توسط گروهی کوچکی که مسئولیت ویراستای ندارند (آن‌ها تنها تغییراتی را که توسط توسعه‌دهندگان موجود در این لیست پستی تایید شده باشند، تنظیم می‌کنند) تایید و تنظیم می‌شوند. شما می‌توانید طرح‌های اصلاحی اخیر را از طریق سامانه عیب‌یابی مشاهده کنید:
خط‌مشی، همچنین شامل جنبه‌های فنی بسته‌بندی نرم‌افزار نیز می‌شود. اندازه پروژه می‌تواند مشکلاتی در رابطه با سازماندهی آن بوجود آورد؛ این مسائل توسط قانون اساسی دبیان مورد ارزیابی قرار می‌گیرند، که ساختار و ابزار مورد نیاز تصمیم‌گیری را فراهم می‌آورد. به عبارت دیگر، یک سامانه قانون‌گذاری رسمی.
این قانون اساسی تعدادی نقش و موقعیت را تعریف می‌کند، به علاوه مسئپولیت‌ها و قدرت اجرایی برای هر کدام. این نکته بسیار حائز اهمیت است که بدانیم توسعه‌دهندگان دبیان همیشه قدرت تصمیم‌گیری نهایی را در اختیار دارند با یک رای مبتنی بر اکثریت، که در آن ۷۵٪ از آرا جهت ایجاد تغییرات بنیادین مورد نیاز است (مانند تغییراتی که اسناد مرتبط با بنیاد را شامل می‌شوند). اگرچه، توسعه‌دهندگان به صورت سالیانه یک “رهبر” را به نمایندگی خود و برای ارتباط با تیم‌های گوناگون، انتخاب می‌کنند. این انتخاب شامل گفتگوهای جدی در طول زمان است. نقش این رهبر به صورت رسمی در هیچ سندی ذکر نشده است: کاندیدای این سمت، تعریف خود را از موقعیت انتخابی ارائه می‌دهد. در عمل، نقش‌های مرتبط با رهبر شامل تعامل با رسانه‌های مختلف، هماهنگی بین تیم‌های “داخلی” و ارائه راهنمایی‌های کلی در قبال پروژه‌ای است که توسعه‌دهندگان مربوط به آن هستند: افکار و ایده‌های رهبر (DPL) به طور ضمنی توسط اکثریت اعضای پروژه مورد تایید قرار می‌گیرد.
به طور خاص، رهبر قدرت حقیقی دارد؛ رای اوست که تعیین‌کننده رای‌های مساوی است؛ همچنین می‌تواند تصمیماتی بگیرد که هم اکنون تحت قدرت اجرایی هیچ فرد دیگری نیست و می‌توانند بخشی از مسئولیت‌های آنان را برعهده بگیرند.
از ابتدای مسیر تاکنون، پروژه توسط آین مرداک، بروس پرنس، آین جکسون، ویچرت آکرمن، بن کالینز، دیل گاربی، مارتین میشل‌مایر، برندن رابینسون، آنتونی تاونز، سام هوکوار، استیو مک‌اینتره، استفانو زاخیرولی و لوکاس ناسبام با موفقیت اداره شده است.
قانون اساسی همچنین شامل یک “کمیته فنی” نیز هست. نقش اساسی این کمیته، تصمیم‌گیری در حالت‌هایی است که توسعه‌دهندگان نسبت به آن نظر واحدی ندارند. در غیر اینصورت، این کمیته نقش مشورتی برای تمام توسعه‌دهندگانی را بازی می‌کند که نسبت به مسئولیت‌های خود قادر به تصمیم‌گیری نهایی نیستند. لازم به ذکر است که این کمیته تا زمانی که از آن دعوت به همکاری نشود، فعالیتی انجام نمی‌دهد.
در نهایت، قانون اساسی موقعیت یک “دبیر پروژه” را تعیین می‌کند، کسی که مسئول سازماندهی رای‌های گوناگون و تصمیمات عمومی است.
فرآیند “تصمیم‌گیری عمومی” با جزئیات کامل در قانون اساسی آمده است، از گفتگوهای اولیه گرفته تا رای‌شماری نهایی. برای اطلاعات بیشتر به ... مراجعه کنید:
حتی اگر این قانون اساسی مشابهتی با دموکراسی داشته باشد، واقعیت روزانه چیز دیگری می‌گوید: دبیان به صورت طبیعی از قوانین نرم‌افزار آزاد در رابطه با do-ocracy تبعیت می‌کند: کسی که کاری انجام می‌دهد، تصمیمات مربوط به چگونگی انجام آن را نیز بر عهده دارد. زمان بسیار زیادی می‌تواند تلف شود اگر بابت حل هر مساله، روش‌های گوناگونی مطرح شود؛ راه حل انتخاب شده اولین موردی خواهد بود که هم کاربردی باشد هم راضی‌کننده... که از زمان گذاشتن فردی شایسته برای حل آن مشکل بیرون می‌آید.
این تنها راهی است که می‌توان کسی را جذب کرد: انجام کاری مفید و نمایش اینکه این کار ممکن است. بسیاری از تیم‌های “مدیریتی” دبیان همکار جدید می‌پذیرند، به خصوص داوطلبانی که شایستگی خود را از قبل ثابت کرده باشند. طبیعت عمومی کاری که در این تیم‌ها انجام می‌شود این امکان را برای مشارکت‌کنندگان جدید بوجود می‌آورد که بدون دسترسی خاصی به پروژه کمک کنند. این همان دلیلی است که همکاری در دبیان با نام “شایسته‌سالاری” شناخته می‌شود.
این شیوه اجرایی موثر، کیفیت مشارکت‌کنندگان در تیم‌های “کلیدی” دبیان را تضمین می‌کند. این روش به هیچ وجه کامل نیست و افرادی وجود دارند که آن را قبول نداشته باشند. انتخاب توسعه‌دهندگانی که در تیم‌ها مورد پذیرش واقع شدند ممکن است دلخواه به نظر آید یا حتی غیرعادلانه. علاوه بر این، هر کسی تعریف یکسانی از سرویس‌‌های مورد انتظار این تیم‌ها را ندارد. برای برخی تیم‌ها، انتظار هشت روزه برای ایجاد یک بسته جدید دبیان غیرقابل قبول، در صورتی که برای سایر تیم‌ها، این انتظار بدون هیچ مشکلی تا سه هفته به طول می‌انجامد. به همین دلیل، ناراضایتی‌های مداومی در رابطه با “کیفیت خدمات” برخی از این تیم‌ها وجود دارد.

1.3.2. نقش فعال کاربران

ممکن است تعجب کنید که آیا نامی از کاربران به عنوان افرادی که در پروژه مشارکت می‌کنند آورده می‌شود یا خیر، پاسخ یک بله قطعی است: کاربران نقش حیاتی در پروژه ایفا می‌کنند. جدای از “غیرفعال” بودن برخی، تعدادی از کاربران نسخه‌های تحت توسعه از دبیان را آزمون می‌کنند و گزارش خرابی آن را ارائه می‌دهند. برخی نیز گام را فراتر گذاشته و ایده‌هایی نوین ارائه می‌دهند، با گزارش باگ در سطح “wishlist” یا حتی اصلاحاتی برای سورس کد با نام “patch” ارائه می‌دهند (به قسمت بازگشت به مقدمات Patch, راهی برای ارسال وصله مراجعه کنید).
علاوه بر این، بسیاری از افراد که خدمات دبیان را مطبوع نظرشان می‌بینند، علاقه دارند تا مشارکت خود را به پروژه نشان دهند. با اینکه هر کسی توانایی کافی جهت برنامه‌نویسی را ندارد، برخی تصمیم می‌گیرند که در فرآیند ترجمه یا مستندسازی مشارکت کنند. برای این منظور، میلینگ لیست‌های متفاوتی به تفکیک هر زبان وجود دارد.
تمام این مکانیزم‌های مشارکت توسط رفتار کاربران بهینه شده است. جامعه‌کاربری، تنها افراد منزوی با ابزارهای خاص خود نیستند، بلکه به معنای حقیقی کلمه جامعه کاربری هستند که می‌توانند با یکدیگر تبادل سازنده داشته باشند. ما به طور خاص به فعالیت چشمگیر در میلینگ لیست مخصوص به کاربران صحبت می‌کنیم، (برای اطلاعات بیشتر به فصل 7, حل مشکلات و یافتن اطلاعات مرتبط مراجعه کنید).
نه تنها کاربران در مسائل فنی که مستقیم آن‌ها را درگیر می‌کند، به یکدیگر (و سایرین) یاری می‌رسانند، بلکه درباره مشارکت در دبیان و پیشبرد اهداف آن نیز همکاری دارند - گفتگوهایی که معمولا به پیشنهادهای سازنده ختم می‌شود.
از آنجایی که دبیان هزینه‌ای بابت بازاریابی خود انجام نمی‌دهد، کاربران آن نقش مهمی در این زمینه ایفا می‌کنند، به خصوص انتشار زبانی موضوعات مرتبط با پروژه دبیان.
این شیوه به خوبی عمل می‌کند، چراکه کاربران دبیان در هر سطحی از جامعه نرم‌افزار آزاد وجود دارند: از فستیوال‌های نصب گرفته (کارگاه‌هایی که کاربران قدمی‌تر، جدیدترها را در فرآیند نصب یاری می‌کنند) که توسط لاگ‌ها یا “گروه‌های کاربری لینوکس” سازماندهی می‌شوند تا کنفرانس‌های بزرگ دنیای فناوری که در آن‌ها از لینوکس و ابزار مرتبط بسیار استفاده می‌شود.
داوطلبان با ایجاد پوستر، بروشور، استیکر و سایر ابزارهای تبلیغاتی برای پروژه، که برای همه قابل دسترس هستند و دبیان آن‌ها را به صورت آزادانه در وبسایت قرار می‌دهد، به این فرآیند یاری می‌رسانند:

1.3.3. تیم‌ها و پروژه‌های جانبی

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

1.3.3.1. پروژه‌های جانبی موجود در دبیان

برای هر سلیقه‌ای، یک نسخه از دبیان وجود دارد!‌ یک پروژه جانبی شامل داوطلبانی می‌شود که دبیان را منطبق با یک نیاز خاص تنظیم می‌کنند. در کنار انتخاب گروهی از برنامه‌ها برای یک حوزه خاص (آموزش، درمان، تولید محتوای چندرسانه‌ای و ...) پروژه‌های جانبی در بهبود بسته‌های موجود نیز دخیل هستند، بسته‌بندی نرم‌افزارهای غیرموجود، انطباق فرآیند نصب با یک نیاز خاص، ایجاد مستندات خاص و بسیاری موارد دیگر.
این فهرست کوچکی از پروژه‌های جانبی دبیان است:
  • Debian-Junior توسط بن آرمسترانگ، یک سامانه دلپذیر و ساده از دبیان را به کودکان ارائه می‌دهد؛
  • Debian-Edu توسط پیتر رینهولدشتین، با تمرکز بر ایجاد توزیع مناسب برای دنیای آموزش؛
  • Debian Med توسط آندریاس تیله، تقدیم به دنیای پزشکی؛
  • Debian Multimedia که با فعالیت‌های صوتی و تصویری سر و کار دارد؛
  • Debian-Desktop که تمرکز اصلی آن بر میزکار گرافیکی است که شامل بهینه‌سازی‌های گرافیکی برای قالب پیش‌فرض است.
  • Debian GIS که مختص کاربران سامانه‌های اطلاعاتی جغرافیایی است؛
  • در نهایت، Debian Accessibility که دبیان را برای افراد با طیف گسترده‌ای از ناتوانی‌ها گسترش می‌دهد.
این فهرست به مرور زمان کامل‌تر شده با اهداف پروژه‌های جانبی دبیان بهبود‌های بیشتری می‌یابد. با پشتیبانی کامل از طرف زیرساخت دبیان، آن‌ها می‌توانند تمرکز خود را بر ارزش افزوده حقیقی قرار دهند، بدون آنکه نگرانی همگام‌سازی با دبیان را داشته باشند، چراکه از درون خود پروژه توسعه می‌یابند.

1.3.3.2. تیم‌های مدیریتی

اکثر تیم‌های مدیریتی به صورت بسته کار می‌کنند و تنها در شرایط همکاری، اقدام به جذب کارآموز می‌نمایند. بهتری شیوه‌ای که می‌توانید عضو این تیم‌ها شوید این است که به صورت هوشمندانه به اعضای فعال آن یاری رسانید و نشان دهید که اهداف اصلی آن‌ها را درک می‌کنید.
تیم ftpmasters مسئول بایگانی رسمی بسته‌های دبیان هستند. آن‌ها برنامه‌ای را نگهداری می‌کنند که بسته‌های دریافتی از توسعه‌دهندگان را دریافت کرده و پس از بررسی‌های اولیه، آن را روی سرورهای دبیان بارگذاری می‌کند (ftp-master.debian.org).
آن‌ها همچنین باید مجوزهای بسته‌های جدید را بررسی کنند، به منظور اینکه با پروژه دبیان سازگاری داشته باشد قبل از اینکه به فهرست بسته‌های موجود اضافه گردند. وقتی که یک توسعه‌دهنده می‌خواهد بسته‌ای را حذف کند، آن‌ها این تیم را با استفاده از سامانه مدیریت باگ فراخوانی کرده و از “شبه‌-بسته” ftp.debian.org برای اینکار استفاده می‌کنند.
تیم Debian System Administrators یا DSA ()، همانطور که ممکن است حدس بزنید مسئول مدیریت سرورهای مختلفی است که پروژه دبیان از آن‌ها استفاده می‌کند. آن‌ها عملکرد بهینه تمام سرویس‌های پایه را تضمین می‌کنند (دی‌ان‌اس، وب، ایمیل، شل و ...)، نرم‌افزار مورد نیاز سایر توسعه‌دهندگان را نصب می‌کنند و تمام اقدامات مرتبط با امنیت را در نظر می‌گیرند.
listmasters ایمیل سروری را مدیریت می‌کنند که تمام میلینگ لیست‌ها در آن قرار دارد. آن‌ها فهرست‌های جدید را ایجاد، اطلاعیه‌های مرتبط با مشکلات آن را پیگیری و فیلترهای اسپم (ایمیل‌های ناخواسته) را بازبینی می‌کنند.
هر سرویس خاصی، تیم مدیریتی خود را دارد، که در مجموع از داوطلبینی که آن‌ها را نصب کرده‌اند تشکیل می‌شود (و آن‌هایی که بطور مداوم در فرآیند توسعه مشارکت دارند). این موضوع در رابطه با سامانه ردیابی باگ (BTS)، ردیاب بسته، alioth.debian.org (سرور FusionForge، قسمت ابزار FusionForge, جعبه‌ابزاری برای مشارکت سازنده را مشاهده کنید)، سرویس‌های موجود در qa.debian.org، lintian.debian.org، buildd.debian.org، cdimage.debian.org و موارد دیگر صدق می‌کند.

1.3.3.3. تیم‌های توسعه، تیم‌های عرضی

برخلاف تیم‌های مدیریتی، تیم‌های توسعه معمولاً بسیار باز هستند، حتی برای مشارکت‌کنندگان خارج از پروژه. حتی اگر دبیان ارتباطی با ایجاد نرم‌افزار نداشته باشد، پروژه به برخی برنامه‌های خاص برای رسیدن به اهدافش نیاز دارد. البته، تحت توسعه یک مجوز نرم‌افزار آزاد، این ابزارها با استفاده از روش‌های گوناگونی در دنیای نرم‌افزار آزاد ساخته می‌شوند.
دبیان در این زمینه نرم‌افزار خاص خود را ندارد، اما برخی برنامه‌ها نقش کلیدی بازی می‌کنند که اعتبار آن‌ها فراتر از حوزه پروژه را شامل می‌شوند. نمونه‌های خوب عبارتند از dpkg، برنامه مدیریت بسته دبیان (که در حقیقت محفف Debian PacKaGe است و بصورت “dee-package” تلفظ می‌شود) و apt، ابزاری که بصورت خودکار یک بسته دبیان را نصب می‌کند، همچنین وابستگی‌های مربوط به آن را که این امر جامعیت سیستم پس از بروزرسانی‌های گوناگون را حفظ می‌کند (که مخفف Advanced Package Tool است). تیم‌های مربوط به این دو، کوچکتر از سایر تیم‌ها هستند، چراکه درک عمیقی از برنامه‌نویسی و چگونگی عملکرد کل سیستم برای آن‌ها مورد نیاز است.
مهمترین تیم به احتمال زیاد مربوط به برنامه نصب‌کننده دبیان، debian-installer است، که کاری مهم و حیاتی را از ابتدای طرح شدن این ایده در سال ۲۰۰۱ انجام داده است. مشارکت‌کنندگانی فراوانی مورد نیاز هستند، چراکه نوشتن یک برنامه که روی تمام معماری‌های موجود نصب شود، کار دشواری است. هر یک مکانیزم بوت خاص خود و بوت‌لودر متفاوتی را شامل می‌شوند. تمام این کارها در میلینگ لیست هماهنگ شده است که زیر نظر سایریل برولبویس قرار دارد.
تیم برنامه (کوچک) debian-cd دیدگاه متواضع‌تری دارد. بسیاری مشارکت‌کنندگان “کوچک” مسئول معماری‌های تحت نظر خود هستند، چراکه هر توسعه‌دهنده نه تنها پیچیدگی‌های خاص هر معماری، بلکه روش صحیح اجرای برنامه از روی CD-ROM را نیز نمی‌داند.
بسیاری از تیم‌ها در فعالیت بسته‌بندی باید با یکدیگر مشارکت داشته باشند: برای نمونه، تلاش می‌کند کیفیت لازم در تمام سطوح پروژه دبیان را تضمنی نماید. فهرست خط‌مشی کلی دبیان را بر اساس طرح‌های اولیه، توسعه می‌دهد. تیم‌های مسئول هر معماری () تمام بسته‌ها را کامپایل و آن‌ها را بر اساس هر معماری منطبق می‌سازد.
سایر تیم‌ها مهمترین بسته‌های موجود را مدیریت می‌کنند تا فرآیند نگهداری از بسته‌ها بدون سنگین شدن یکی از آن‌ها، تضمین شود؛ این مورد درباره کتابخانه C صادق است و ، کامپایلر C در فهرست یا Xorg در فهرست (این گروه با نام گروه ضربت X معروف است).