نتیجه نهایی که از پروژه دبیان نشات می‌گیرد وابسته به زیرساخت موجودی است که توسط بسیاری توسعه‌دهندگان حرفه‌ای دبیان مدیریت می‌شود، خواه کار انفرادی یا گروهی توسعه‌دهندگان بر روی بسته‌های دبیان خواه از بازخوردهای دریافتی از کاربران.
1.3.1. توسعه‌دهندگان دبیان
Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams, thus acquiring more responsibilities within the project.
Package maintenance is a relatively regimented activity, very documented or even regulated. It must, in effect, comply with all the standards established by the
Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as squashing bugs.
The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the
debian-policy@lists.debian.org mailing list. Amendments that are agreed upon by all interested parties are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:
خط‌مشی، همچنین شامل جنبه‌های فنی بسته‌بندی نرم‌افزار نیز می‌شود. اندازه پروژه می‌تواند مشکلاتی در رابطه با سازماندهی آن بوجود آورد؛ این مسائل توسط قانون اساسی دبیان مورد ارزیابی قرار می‌گیرند، که ساختار و ابزار مورد نیاز تصمیم‌گیری را فراهم می‌آورد. به عبارت دیگر، یک سامانه قانون‌گذاری رسمی.
این قانون اساسی تعدادی نقش و موقعیت را تعریف می‌کند، به علاوه مسئپولیت‌ها و قدرت اجرایی برای هر کدام. این نکته بسیار حائز اهمیت است که بدانیم توسعه‌دهندگان دبیان همیشه قدرت تصمیم‌گیری نهایی را در اختیار دارند با یک رای مبتنی بر اکثریت، که در آن ۷۵٪ از آرا جهت ایجاد تغییرات بنیادین مورد نیاز است (مانند تغییراتی که اسناد مرتبط با بنیاد را شامل می‌شوند). اگرچه، توسعه‌دهندگان به صورت سالیانه یک “رهبر” را به نمایندگی خود و برای ارتباط با تیم‌های گوناگون، انتخاب می‌کنند. این انتخاب شامل گفتگوهای جدی در طول زمان است. نقش این رهبر به صورت رسمی در هیچ سندی ذکر نشده است: کاندیدای این سمت، تعریف خود را از موقعیت انتخابی ارائه می‌دهد. در عمل، نقش‌های مرتبط با رهبر شامل تعامل با رسانه‌های مختلف، هماهنگی بین تیم‌های “داخلی” و ارائه راهنمایی‌های کلی در قبال پروژه‌ای است که توسعه‌دهندگان مربوط به آن هستند: افکار و ایده‌های رهبر (DPL) به طور ضمنی توسط اکثریت اعضای پروژه مورد تایید قرار می‌گیرد.
به طور خاص، رهبر قدرت حقیقی دارد؛ رای اوست که تعیین‌کننده رای‌های مساوی است؛ همچنین می‌تواند تصمیماتی بگیرد که هم اکنون تحت قدرت اجرایی هیچ فرد دیگری نیست و می‌توانند بخشی از مسئولیت‌های آنان را برعهده بگیرند.
Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Mehdi Dogguy, Chris Lamb and Sam Hartman.
قانون اساسی همچنین شامل یک “کمیته فنی” نیز هست. نقش اساسی این کمیته، تصمیم‌گیری در حالت‌هایی است که توسعه‌دهندگان نسبت به آن نظر واحدی ندارند. در غیر اینصورت، این کمیته نقش مشورتی برای تمام توسعه‌دهندگانی را بازی می‌کند که نسبت به مسئولیت‌های خود قادر به تصمیم‌گیری نهایی نیستند. لازم به ذکر است که این کمیته تا زمانی که از آن دعوت به همکاری نشود، فعالیتی انجام نمی‌دهد.
در نهایت، قانون اساسی موقعیت یک “دبیر پروژه” را تعیین می‌کند، کسی که مسئول سازماندهی رای‌های گوناگون و تصمیمات عمومی است.
The “general resolution” procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a
Condorcet method (more specifically, the Schulze method). For further details see:
حتی اگر این قانون اساسی مشابهتی با دموکراسی داشته باشد، واقعیت روزانه چیز دیگری می‌گوید: دبیان به صورت طبیعی از قوانین نرم‌افزار آزاد در رابطه با do-ocracy تبعیت می‌کند: کسی که کاری انجام می‌دهد، تصمیمات مربوط به چگونگی انجام آن را نیز بر عهده دارد. زمان بسیار زیادی می‌تواند تلف شود اگر بابت حل هر مساله، روش‌های گوناگونی مطرح شود؛ راه حل انتخاب شده اولین موردی خواهد بود که هم کاربردی باشد هم راضی‌کننده... که از زمان گذاشتن فردی شایسته برای حل آن مشکل بیرون می‌آید.
این تنها راهی است که می‌توان کسی را جذب کرد: انجام کاری مفید و نمایش اینکه این کار ممکن است. بسیاری از تیم‌های “مدیریتی” دبیان همکار جدید می‌پذیرند، به خصوص داوطلبانی که شایستگی خود را از قبل ثابت کرده باشند. طبیعت عمومی کاری که در این تیم‌ها انجام می‌شود این امکان را برای مشارکت‌کنندگان جدید بوجود می‌آورد که بدون دسترسی خاصی به پروژه کمک کنند. این همان دلیلی است که همکاری در دبیان با نام “شایسته‌سالاری” شناخته می‌شود.
این شیوه اجرایی موثر، کیفیت مشارکت‌کنندگان در تیم‌های “کلیدی” دبیان را تضمین می‌کند. این روش به هیچ وجه کامل نیست و افرادی وجود دارند که آن را قبول نداشته باشند. انتخاب توسعه‌دهندگانی که در تیم‌ها مورد پذیرش واقع شدند ممکن است دلخواه به نظر آید یا حتی غیرعادلانه. علاوه بر این، هر کسی تعریف یکسانی از سرویسهای مورد انتظار این تیم‌ها را ندارد. برای برخی تیم‌ها، انتظار هشت روزه برای ایجاد یک بسته جدید دبیان غیرقابل قبول، در صورتی که برای سایر تیم‌ها، این انتظار بدون هیچ مشکلی تا سه هفته به طول می‌انجامد. به همین دلیل، ناراضایتی‌های مداومی در رابطه با “کیفیت خدمات” برخی از این تیم‌ها وجود دارد.
One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see
قسمت 1.3.2.3, “Sending fixes”
).
The fundamental tool for submitting bugs in Debian is the Debian Bug Tracking System (Debian BTS), which is used by large parts of the project. The public part (the web interface) allows users to view all bugs reported, with the option to display a sorted list of bugs selected according to various criteria, such as: affected package, severity, status, address of the reporter, address of the maintainer in charge of it, tag, etc. It is also possible to browse the complete historical listing of all discussions regarding each of the bugs.
سامانه ردیابی باگ دبیان (BTS) توسط قسمت‌های بزرگی از پروژه استفاده می‌شود. قسمت عمومی آن (رابط گرافیکی وب) به کاربران امکان مشاهده تمام باگ‌ها را می‌دهد با انتخاب مرتب‌سازی باگ بر اساس شرایط گوناگون مانند: بسته تاثیرپذیر، میزان حساسیت، وضعیت، نشانی گزارش‌کننده آن، نشانی توسعهدهنده بسته، تگ و موارد دیگر. همچنین امکان جستجو در تمام گفتگوهای صورت گرفته در مورد یک باگ خاص وجود دارد.
در پشت صحنه، این سامانه مبتنی بر ایمیل است: تمام اطلاعاتی که ذخیره می‌کند از پیام‌های ارسال شده توسط دیگران نشات می‌گیرد. هر ایمیلی که به
12345@bugs.debian.org فرستاده شود به عنوان تاریخچه‌ای از باگ شماره ۱۲۳۴۵ در نظر گرفته می‌شود. اعضای مجاز پروژه می‌توانند با ارسال ایمیل به
12345-done@bugs.debian.org یک باگ را “ببندد” (یک باگ زمانی بسته می‌شود که یا مشکلش رفع شده باشد یا بحث مرتبطی درباره آن وجود نداشته باشد). یک باگ جدید با فرستادن ایمیل به
submit@bugs.debian.org با توجه به فرمت خاص هر بسته، ایجاد می‌شود. نشانی
control@bugs.debian.org برای ویرایش “اطلاعات جانبی” درباره یک باگ استفاده می‌شود.
The Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see
Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).
این ابزار در ابتدا نسخه‌های تحت توسعه را هدف می‌گیرد، که باگ برای آن‌ها ارسال شده است. به همین منظور، تغییرات در نسخه‌های پایدار دبیان مورد قبول واقع نمی‌شوند مگر در مواقع خاص مانند بروزرسانی‌های امنیتی یا سایر بروزرسانی‌های مهم (اگر، برای نمونه، یک بسته اصلا کار نکند). اصلاح باگ در یک بسته دبیان، تا انتشار نسخه پایدار بعدی آن به عقب می‌افتد.
1.3.2.2. Translation and documentation
Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they may choose to assist with the translation and review of documentation. There are language-specific mailing lists to coordinate this work.
More advanced users might be able to provide a fix to a program sending a patch.
یک patch فایلی است که نشانگر تغییرات مورد نیاز در فایل‌های مرجع دیگر می‌باشد. به طور خاص، شامل خطوطی است که از فایل باید حذف یا به آن اضافه شوند، همینطور (گاهی) خطوطی که از متن اصلی گرفته شده‌اند و جایگزین تغییرات مورد نظر می‌شوند (آن‌ها امکان شناسایی محل قرارگیری این خطوط را می‌دهند حتی اگر شماره خطشان عوض شده باشد).
یک patch فایلی است که نشانگر تغییرات مورد نیاز در فایل‌های مرجع دیگر می‌باشد. به طور خاص، شامل خطوطی است که از فایل باید حذف یا به آن اضافه شوند، همینطور (گاهی) خطوطی که از متن اصلی گرفته شده‌اند و جایگزین تغییرات مورد نظر می‌شوند (آن‌ها امکان شناسایی محل قرارگیری این خطوط را می‌دهند حتی اگر شماره خطشان عوض شده باشد).
ابزاری که برای ایجاد تغییرات مورد نظر در این فایل‌ها استفاده می‌شود patch و ابزاری که این فایل patch را بوجود می‌آورد diff نام دارد و به شکل زیر استفاده می‌شود:
$ diff -u file.old file.new >file.patch
فایل file.patch شامل دستوراتی است که فایل file.old را به file.new تغییر می‌دهد. می‌توانیم آن را برای کسی بفرستیم تا فایل file.new را بازآفرینی کند، مانند این:
$ patch -p0 file.old <file.patch
فایل file.old اکنون همانند file.new است.
1.3.2.4. Other ways of contributing
تمام این مکانیزم‌های مشارکت توسط رفتار کاربران بهینه شده است. جامعه‌کاربری، تنها افراد منزوی با ابزارهای خاص خود نیستند، بلکه به معنای حقیقی کلمه جامعه کاربری هستند که می‌توانند با یکدیگر تبادل سازنده داشته باشند. ما به طور خاص به فعالیت چشمگیر در میلینگ لیست مخصوص به کاربران صحبت می‌کنیم،
debian-user@lists.debian.org (برای اطلاعات بیشتر به
فصل 7, حل مشکلات و یافتن اطلاعات مرتبط مراجعه کنید).
نه تنها کاربران در مسائل فنی که مستقیم آن‌ها را درگیر می‌کند، به یکدیگر (و سایرین) یاری می‌رسانند، بلکه درباره مشارکت در دبیان و پیشبرد اهداف آن نیز همکاری دارند - گفتگوهایی که معمولا به پیشنهادهای سازنده ختم می‌شود.
از آنجایی که دبیان هزینه‌ای بابت بازاریابی خود انجام نمی‌دهد، کاربران آن نقش مهمی در این زمینه ایفا می‌کنند، به خصوص انتشار زبانی موضوعات مرتبط با پروژه دبیان.
This method works quite well, since Debian fans are found at all levels of the free software community: from install parties (workshops where seasoned users assist newcomers to install the system) organized by local LUGs or “Linux User Groups”, to association booths at large tech conventions dealing with Linux, etc.
Volunteers make posters, brochures, stickers, and other useful promotional materials for the project, which they make available to everyone, and which Debian provides freely on its website and on its wiki:
1.3.3. تیم‌ها و پروژه‌های جانبی
دبیان از همان ابتدا بر مفهوم بسته‌های سورس، بنیان‌گذاری شده بود، که هر یک گروهی از توسعه‌دهندگان مربوط به خود را داشت. بسیاری از تیم‌ها به مرور زمان با یکدیگر تلفیق شده‌اند، تا از مدیریت زیرساخت، راهبری فعالیت‌هایی که به یک بسته خاص تعلق ندارند (تضمین کیفیت، خط‌مشی دبیان، نصب‌کننده و ...) اطمینان یابند، با استفاده از آخرین تیم‌هایی که پیرامون پروژه‌های جانبی شکل می‌گیرند.
1.3.3.1. پروژه‌های جانبی موجود در دبیان
برای هر سلیقه‌ای، یک نسخه از دبیان وجود دارد! یک پروژه جانبی شامل داوطلبانی می‌شود که دبیان را منطبق با یک نیاز خاص تنظیم می‌کنند. در کنار انتخاب گروهی از برنامه‌ها برای یک حوزه خاص (آموزش، درمان، تولید محتوای چندرسانه‌ای و ...) پروژه‌های جانبی در بهبود بسته‌های موجود نیز دخیل هستند، بسته‌بندی نرم‌افزارهای غیرموجود، انطباق فرآیند نصب با یک نیاز خاص، ایجاد مستندات خاص و بسیاری موارد دیگر.
این فهرست کوچکی از پروژه‌های جانبی دبیان است:
Debian Jr., by Ben Armstrong, offering an appealing and easy to use Debian system for children;
Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic world;
Debian Med توسط آندریاس تیله، تقدیم به دنیای پزشکی؛
Debian Multimedia که با فعالیت‌های صوتی و تصویری سر و کار دارد؛
Debian GIS که مختص کاربران سامانه‌های اطلاعاتی جغرافیایی است؛
Debian Accessibility, improving Debian to match the requirements of people with disabilities;
Debian Science, finally, working on providing researchers and scientists a better experience using Debian.
DebiChem, targeted at Chemistry, provides chemical suites and programs.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian sub-projects. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.
اکثر تیم‌های مدیریتی به صورت بسته کار می‌کنند و تنها در شرایط همکاری، اقدام به جذب کارآموز می‌نمایند. بهتری شیوه‌ای که می‌توانید عضو این تیم‌ها شوید این است که به صورت هوشمندانه به اعضای فعال آن یاری رسانید و نشان دهید که اهداف اصلی آن‌ها را درک می‌کنید.
تیم ftpmasters مسئول بایگانی رسمی بسته‌های دبیان هستند. آن‌ها برنامه‌ای را نگهداری می‌کنند که بسته‌های دریافتی از توسعه‌دهندگان را دریافت کرده و پس از بررسی‌های اولیه، آن را روی سرورهای دبیان بارگذاری می‌کند (ftp-master.debian.org).
آن‌ها همچنین باید مجوزهای بسته‌های جدید را بررسی کنند، به منظور اینکه با پروژه دبیان سازگاری داشته باشد قبل از اینکه به فهرست بسته‌های موجود اضافه گردند. وقتی که یک توسعهدهنده می‌خواهد بسته‌ای را حذف کند، آن‌ها این تیم را با استفاده از سامانه مدیریت باگ فراخوانی کرده و از “شبه-بسته” ftp.debian.org برای اینکار استفاده می‌کنند.
تیم
Debian System Administrators یا DSA (
debian-admin@lists.debian.org)، همانطور که ممکن است حدس بزنید مسئول مدیریت سرورهای مختلفی است که پروژه دبیان از آن‌ها استفاده می‌کند. آن‌ها عملکرد بهینه تمام سرویسهای پایه را تضمین می‌کنند (دی‌ان‌اس، وب، ایمیل، شل و ...)، نرم‌افزار مورد نیاز سایر توسعه‌دهندگان را نصب می‌کنند و تمام اقدامات مرتبط با امنیت را در نظر می‌گیرند.
listmasters ایمیل سروری را مدیریت می‌کنند که تمام میلینگ لیست‌ها در آن قرار دارد. آن‌ها فهرست‌های جدید را ایجاد، اطلاعیه‌های مرتبط با مشکلات آن را پیگیری و فیلترهای اسپم (ایمیل‌های ناخواسته) را بازبینی می‌کنند.
Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case of the bug tracking system (BTS), the package tracker,
salsa.debian.org (GitLab server, see sidebar
TOOL GitLab, Git repository hosting and much more), the services available on
qa.debian.org,
lintian.debian.org,
buildd.debian.org,
cdimage.debian.org, etc.
1.3.3.3. تیم‌های توسعه، تیم‌های عرضی
برخلاف تیم‌های مدیریتی، تیم‌های توسعه معمولاً بسیار باز هستند، حتی برای مشارکت‌کنندگان خارج از پروژه. حتی اگر دبیان ارتباطی با ایجاد نرم‌افزار نداشته باشد، پروژه به برخی برنامه‌های خاص برای رسیدن به اهدافش نیاز دارد. البته، تحت توسعه یک مجوز نرم‌افزار آزاد، این ابزارها با استفاده از روش‌های گوناگونی در دنیای نرم‌افزار آزاد ساخته می‌شوند.
دبیان در این زمینه نرم‌افزار خاص خود را ندارد، اما برخی برنامه‌ها نقش کلیدی بازی می‌کنند که اعتبار آن‌ها فراتر از حوزه پروژه را شامل می‌شوند. نمونه‌های خوب عبارتند از dpkg، برنامه مدیریت بسته دبیان (که در حقیقت محفف Debian PacKaGe است و بصورت “dee-package” تلفظ می‌شود) و apt، ابزاری که بصورت خودکار یک بسته دبیان را نصب می‌کند، همچنین وابستگی‌های مربوط به آن را که این امر جامعیت سیستم پس از بروزرسانی‌های گوناگون را حفظ می‌کند (که مخفف Advanced Package Tool است). تیم‌های مربوط به این دو، کوچکتر از سایر تیم‌ها هستند، چراکه درک عمیقی از برنامه‌نویسی و چگونگی عملکرد کل سیستم برای آن‌ها مورد نیاز است.
مهمترین تیم به احتمال زیاد مربوط به برنامه نصب‌کننده دبیان،
debian-installer است، که کاری مهم و حیاتی را از ابتدای طرح شدن این ایده در سال ۲۰۰۱ انجام داده است. مشارکت‌کنندگانی فراوانی مورد نیاز هستند، چراکه نوشتن یک برنامه که روی تمام معماری‌های موجود نصب شود، کار دشواری است. هر یک مکانیزم بوت خاص خود و بوت‌لودر متفاوتی را شامل می‌شوند. تمام این کارها در میلینگ لیست
debian-boot@lists.debian.org هماهنگ شده است که زیر نظر سایریل برولبویس قرار دارد.
تیم برنامه (کوچک) debian-cd دیدگاه متواضع‌تری دارد. بسیاری مشارکت‌کنندگان “کوچک” مسئول معماری‌های تحت نظر خود هستند، چراکه هر توسعهدهنده نه تنها پیچیدگی‌های خاص هر معماری، بلکه روش صحیح اجرای برنامه از روی CD-ROM را نیز نمی‌داند.
