Product SiteDocumentation Site

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

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

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 and projects, 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 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:
The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.
This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.
به طور خاص، رهبر قدرت حقیقی دارد؛ رای اوست که تعیین‌کننده رای‌های مساوی است؛ همچنین می‌تواند تصمیماتی بگیرد که هم اکنون تحت قدرت اجرایی هیچ فرد دیگری نیست و می‌توانند بخشی از مسئولیت‌های آنان را برعهده بگیرند.
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, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.
قانون اساسی همچنین شامل یک “کمیته فنی” نیز هست. نقش اساسی این کمیته، تصمیم‌گیری در حالت‌هایی است که توسعه‌دهندگان نسبت به آن نظر واحدی ندارند. در غیر اینصورت، این کمیته نقش مشورتی برای تمام توسعه‌دهندگانی را بازی می‌کند که نسبت به مسئولیت‌های خود قادر به تصمیم‌گیری نهایی نیستند. لازم به ذکر است که این کمیته تا زمانی که از آن دعوت به همکاری نشود، فعالیتی انجام نمی‌دهد.
در نهایت، قانون اساسی موقعیت یک “دبیر پروژه” را تعیین می‌کند، کسی که مسئول سازماندهی رای‌های گوناگون و تصمیمات عمومی است.
The “general resolution” (GR) 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:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.
این تنها راهی است که می‌توان کسی را جذب کرد: انجام کاری مفید و نمایش اینکه این کار ممکن است. بسیاری از تیم‌های “مدیریتی” دبیان همکار جدید می‌پذیرند، به خصوص داوطلبانی که شایستگی خود را از قبل ثابت کرده باشند. طبیعت عمومی کاری که در این تیم‌ها انجام می‌شود این امکان را برای مشارکت‌کنندگان جدید بوجود می‌آورد که بدون دسترسی خاصی به پروژه کمک کنند. این همان دلیلی است که همکاری در دبیان با نام “شایسته‌سالاری” شناخته می‌شود.
این شیوه اجرایی موثر، کیفیت مشارکت‌کنندگان در تیم‌های “کلیدی” دبیان را تضمین می‌کند. این روش به هیچ وجه کامل نیست و افرادی وجود دارند که آن را قبول نداشته باشند. انتخاب توسعه‌دهندگانی که در تیم‌ها مورد پذیرش واقع شدند ممکن است دلخواه به نظر آید یا حتی غیرعادلانه. علاوه بر این، هر کسی تعریف یکسانی از سرویس‌‌های مورد انتظار این تیم‌ها را ندارد. برای برخی تیم‌ها، انتظار هشت روزه برای ایجاد یک بسته جدید دبیان غیرقابل قبول، در صورتی که برای سایر تیم‌ها، این انتظار بدون هیچ مشکلی تا سه هفته به طول می‌انجامد. به همین دلیل، ناراضایتی‌های مداومی در رابطه با “کیفیت خدمات” برخی از این تیم‌ها وجود دارد.

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

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 قسمت, “Sending fixes” ). Reporting bugs

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.
در پشت صحنه، این سامانه مبتنی بر ایمیل است: تمام اطلاعاتی که ذخیره می‌کند از پیام‌های ارسال شده توسط دیگران نشات می‌گیرد. هر ایمیلی که به فرستاده شود به عنوان تاریخچه‌ای از باگ شماره ۱۲۳۴۵ در نظر گرفته می‌شود. اعضای مجاز پروژه می‌توانند با ارسال ایمیل به یک باگ را “ببندد” (یک باگ زمانی بسته می‌شود که یا مشکلش رفع شده باشد یا بحث مرتبطی درباره آن وجود نداشته باشد). یک باگ جدید با فرستادن ایمیل به با توجه به فرمت خاص هر بسته، ایجاد می‌شود. نشانی برای ویرایش “اطلاعات جانبی” درباره یک باگ استفاده می‌شود.
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).
این ابزار در ابتدا نسخه‌های تحت توسعه را هدف می‌گیرد، که باگ برای آن‌ها ارسال شده است. به همین منظور، تغییرات در نسخه‌های پایدار دبیان مورد قبول واقع نمی‌شوند مگر در مواقع خاص مانند بروزرسانی‌های امنیتی یا سایر بروزرسانی‌های مهم (اگر، برای نمونه، یک بسته اصلا کار نکند). اصلاح باگ در یک بسته دبیان، تا انتشار نسخه پایدار بعدی آن به عقب می‌افتد. 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. Sending fixes

More advanced users might be able to provide a fix to a program by sending a patch.
یک patch فایلی است که نشانگر تغییرات مورد نیاز در فایل‌های مرجع دیگر می‌باشد. به طور خاص، شامل خطوطی است که از فایل باید حذف یا به آن اضافه شوند، همینطور (گاهی) خطوطی که از متن اصلی گرفته شده‌اند و جایگزین تغییرات مورد نظر می‌شوند (آن‌ها امکان شناسایی محل قرارگیری این خطوط را می‌دهند حتی اگر شماره خطشان عوض شده باشد).
ابزاری که برای ایجاد تغییرات مورد نظر در این فایل‌ها استفاده می‌شود patch و ابزاری که این فایل patch را بوجود می‌آورد diff نام دارد و به شکل زیر استفاده می‌شود:
$ diff -u file.old >file.patch
فایل file.patch شامل دستوراتی است که فایل file.old را به تغییر می‌دهد. می‌توانیم آن را برای کسی بفرستیم تا فایل را بازآفرینی کند، مانند این:
$ patch -p0 file.old <file.patch
فایل file.old اکنون همانند است.
In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.
While the output of git diff is a file that can be shared with other developers, there are usually better ways to submit changes. If the developers prefer to get patches by email, they usually want patches generated with git format-patch so that they can be directly integrated in the repository with git am. This preserves commits meta-information and makes it possible to share multiple commits at once.
This email-based workflow is still popular but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click. Other ways of contributing

All of these contribution mechanisms are made more efficient by users' behavior. Far from being a collection of isolated persons, users are a true community within which numerous exchanges take place. We especially note the impressive activity on the user discussion mailing list, ( فصل 7, حل مشکلات و یافتن اطلاعات مرتبط discusses this in greater detail).
نه تنها کاربران در مسائل فنی که مستقیم آن‌ها را درگیر می‌کند، به یکدیگر (و سایرین) یاری می‌رسانند، بلکه درباره مشارکت در دبیان و پیشبرد اهداف آن نیز همکاری دارند - گفتگوهایی که معمولا به پیشنهادهای سازنده ختم می‌شود.
از آنجایی که دبیان هزینه‌ای بابت بازاریابی خود انجام نمی‌دهد، کاربران آن نقش مهمی در این زمینه ایفا می‌کنند، به خصوص انتشار زبانی موضوعات مرتبط با پروژه دبیان.
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. Teams, Blends, and Sub-Projects

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends. Existing Debian Sub-Projects and Blends

To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
  • Debian Junior, 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 and educational world;
  • Debian Med توسط آندریاس تیله، تقدیم به دنیای پزشکی؛
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, for both professionals and hobby astronomers;
  • Debian Science, working on providing researchers and scientists a better experience using Debian;
  • Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;
  • Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;
  • 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 Pure Blends. 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. تیم‌های مدیریتی

Most administrative teams are relatively closed and recruit only by co-optation. The best means to become a part of one is to intelligently assist the current members, demonstrating that you have understood their objectives and methods of operation.
The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (
آن‌ها همچنین باید مجوزهای بسته‌های جدید را بررسی کنند، به منظور اینکه با پروژه دبیان سازگاری داشته باشد قبل از اینکه به فهرست بسته‌های موجود اضافه گردند. وقتی که یک توسعه‌دهنده می‌خواهد بسته‌ای را حذف کند، آن‌ها این تیم را با استفاده از سامانه مدیریت باگ فراخوانی کرده و از “شبه‌-بسته” برای اینکار استفاده می‌کنند.
The Debian System Administrators (DSA) team (), as one might expect, is responsible for system administration of the many servers used by the project. They ensure optimal functioning of all base services (DNS, Web, e-mail, shell, etc.), install software requested by Debian developers, and take all precautions in regards to security.
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 for the bug tracking system (BTS), the package tracker, (GitLab server, see sidebar TOOL GitLab, Git repository hosting and much more), the services available on,,,, etc. تیم‌های توسعه، تیم‌های عرضی

برخلاف تیم‌های مدیریتی، تیم‌های توسعه معمولاً بسیار باز هستند، حتی برای مشارکت‌کنندگان خارج از پروژه. حتی اگر دبیان ارتباطی با ایجاد نرم‌افزار نداشته باشد، پروژه به برخی برنامه‌های خاص برای رسیدن به اهدافش نیاز دارد. البته، تحت توسعه یک مجوز نرم‌افزار آزاد، این ابزارها با استفاده از روش‌های گوناگونی در دنیای نرم‌افزار آزاد ساخته می‌شوند.
دبیان در این زمینه نرم‌افزار خاص خود را ندارد، اما برخی برنامه‌ها نقش کلیدی بازی می‌کنند که اعتبار آن‌ها فراتر از حوزه پروژه را شامل می‌شوند. نمونه‌های خوب عبارتند از dpkg، برنامه مدیریت بسته دبیان (که در حقیقت محفف Debian PacKaGe است و بصورت “dee-package” تلفظ می‌شود) و apt، ابزاری که بصورت خودکار یک بسته دبیان را نصب می‌کند، همچنین وابستگی‌های مربوط به آن را که این امر جامعیت سیستم پس از بروزرسانی‌های گوناگون را حفظ می‌کند (که مخفف Advanced Package Tool است). تیم‌های مربوط به این دو، کوچکتر از سایر تیم‌ها هستند، چراکه درک عمیقی از برنامه‌نویسی و چگونگی عملکرد کل سیستم برای آن‌ها مورد نیاز است.
The most important team is probably that for the Debian installation program, debian-installer, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the mailing list, under the direction of Cyril Brulebois.
تیم برنامه (کوچک) debian-cd دیدگاه متواضع‌تری دارد. بسیاری مشارکت‌کنندگان “کوچک” مسئول معماری‌های تحت نظر خود هستند، چراکه هر توسعه‌دهنده نه تنها پیچیدگی‌های خاص هر معماری، بلکه روش صحیح اجرای برنامه از روی CD-ROM را نیز نمی‌داند.
بسیاری از تیم‌ها در فعالیت بسته‌بندی باید با یکدیگر مشارکت داشته باشند: برای نمونه، تلاش می‌کند کیفیت لازم در تمام سطوح پروژه دبیان را تضمنی نماید. فهرست خط‌مشی کلی دبیان را بر اساس طرح‌های اولیه، توسعه می‌دهد. تیم‌های مسئول هر معماری () تمام بسته‌ها را کامپایل و آن‌ها را بر اساس هر معماری منطبق می‌سازد.
سایر تیم‌ها مهمترین بسته‌های موجود را مدیریت می‌کنند تا فرآیند نگهداری از بسته‌ها بدون سنگین شدن یکی از آن‌ها، تضمین شود؛ این مورد درباره کتابخانه C صادق است و ، کامپایلر C در فهرست یا Xorg در فهرست (این گروه با نام گروه ضربت X معروف است).