Product SiteDocumentation Site

1.3. Bagaimana Proyek Debian Bekerja

Karya yang dihasilkan proyek Debian merupakan hasil simultan dari kerja infrastruktur yang dilakukan oleh para pengembang Debian berpengalaman, individu, atau pekerjaan kolektif dari para pengembang paket Debian, dan umpan balik pengguna.

1.3.1. The Debian Developers (Pengembang Debian)

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 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:
Kebijakan memuat aspek teknis pemaketan dengan sangat baik. Ukuran dari proyek juga memunculkan permasalahan organisasi; hal ini ditangani oleh Debian Constitution, yang menyediakan struktur dan mekanisme untuk membuat keputusan.
Konstitusi ini mendefinisikan beberapa peran dan posisi, berikut dengan tanggung jawab dan kewenangannya. Secara khusus perlu diperhatikan bahwa pengembang Debian selalu memiliki kewenangan dalam membuat keputusan terakhir di sidang umum, di mana diperlukan tiga-per-empat (75%) suara diperlukan untuk membuat perubahan (misalnya yang memiliki efek pada Dokumen Yayasan). Biar bagaimanapun, setiap tahunnya pengembang memilih seorang “pemimpin” untuk merepresentasikan mereka dalam pertemuan, dan memastikan koordinasi internal antara beragam tim. Pemilihan ini selalu penuh dengan diskusi intensif. Peran pemimpin tidak didefinisikan secara formal dalam dokumen mana pun: kandidat untuk posisi ini umumnya mengajukan pemahaman mereka sendiri akan posisi pemimpin. Pada praktiknya, peran pemimpin termasuk sebagai perwakilan ke media, koordinasi antara tim “internal”, dan menyediakan panduan umum ke proyek, di mana pengembang dapat menghubungkan: pandangan DPL secara implisit disetujui oleh mayoritas anggota proyek.
Secara khusus, seorang pemimpin memiliki otoritas; hak suaranya memecahkan pemungutan suara seri; ia dapat membuat keputusan apapun yang sebelumnya tak seorang pun memiliki wewenang dan dapat mendelegasikan sebagian tanggung jawabnya.
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.
Konstitusi telah mendefinisikan sebuah “komite teknis”. Peran dasar komite ini adalah memutuskan hal-hal teknis saat para pengembang yang terlibat belum mencapai kesepakatan di antara mereka sendiri. Selain itu, komite ini berperan sebagai penasihat bagi pengembang mana pun yang tidak bisa membuat keputusan yang mereka bertanggung jawab atasnya. Penting untuk dicatat bahwa mereka hanya terlibat saat diundang oleh salah satu pihak yang membutuhkan.
Akhirnya, di dalam konstitusi didefinisikan posisi “sekretaris proyek” yang bertanggung jawab atas proses pemungutan suara dari beragam pemilihan dan sidang umum.
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:
Bahkan jika konstitusi ini menyediakan kemiripan dengan demokrasi, kenyataan sehari-hari cukup berbeda: Debian secara alami mengikuti peraturan perangkat lunak bebas do-ocracy: mereka yang melakukan, mereka yang menentukan. Banyak waktu dapat dihabiskan dengan mendebatkan keuntungan dari beragam pendekatan masalah; solusi yang akan dipilih pertama adalah solusi yang fungsional dan memuaskan... menghargai waktu yang dihabiskan oleh mereka yang kompeten.
Hanya inilah cara untuk mendapatkan kredit: lakukan sesuatu yang berguna dan tunjukkan telah bekerja dengan baik. Banyak tim “administratif” Debian bekerja berdasarkan perjanjian, lebih suka relawan yang telah berkontribusi secara efektif dan membuktikan kompetensinya. Metode ini praktis, karena mayoritas pekerjaan tim ini bersifat publik, sehingga dapat diakses oleh pengembang manapun yang tertarik. Oleh karena inilah Debian sering digambarkan sebagai “meritokrasi”.
Metode efektif operasi ini menjamin kualitas dari kontributor merupakan “kunci” dalam tim Debian. Metode ini bukan berarti sempurna dan sesekali terdapat mereka yang tidak setuju dengan cara kerja ini. Seleski pengembang yang dipilih dalam tim bisa jadi terlihat arbitrer atau bahkan tak adil. Lebih lanjut, tak semuanya memiliki definisi yang sama dari layanan yang diharapkan dari tim ini. Untuk beberapa orang, merupakan hal yang tidak dapat diterima untuk mengguna selama 8 hari untuk memasukkan paket Debian baru, sementara lainnya tidak masalah akan bersabar menunggu selama 3 minggu. Kondisi seperti ini, terdapat keluhan rutin dari mereka yang tidak suka mengenai “kualitas layanan” dari beberapa tim.

1.3.2. Peran Aktif dari Pengguna

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 Bagian 1.3.2.3, “Sending fixes”).

1.3.2.1. 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.
Di bawah permukaan, Debian BTS berbasis surel: semua informasi yang disimpan berasal dari pesan yang dikirim oleh beragam orang yang terlibat. Setiap surel yang dikirim ke akan ditugaskan ke rekam jejak untuk kutu no. 12345. Orang yang berhak dapat “menutup” dengan menulis pesan yang menjelaskan alasan dari keputusan untuk menutup ke (sebuah kutu diungkapkan saat masalah indikasi dipecahkan atau tidak lagi relevan). Kutu baru dilaporkan dengan mengirimkan surel ke berdasarkan format tertentu yang mengidentifikasi paket yang dipertanyakan. Alamat memungkinkan penyuntingan semua “informasi-meta” yang terkait dengan kutu.
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).
Perkakas ini awalnya hanya ditujukan untuk versi pengembangan, yang hanya perhatian dengan penanganan kutu. Akibatnya versi stabil Debianbagaikan tertulis di batu, hanya dengan pengecualian pemutakhiran keamanan atau pemutakhiran lainnya (jika, sebagai contoh, sebuah paket tidak bekerja sama sekali). Koreksi minor dari kutu dalam paket Debian harus menunggu versi stabil berikutnya.

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.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program by sending a patch.
Sebuah patch adalah berkas yang menggambarkan perubahan yang perlu dibuat pada satu atau lebih berkas. Secara khusus, akan berisi daftar baris yang perlu dihapus atau ditambahkan pada kode, begitupun dengan baris yang perlu diambil dari teks referensi, mengganti modifikasi dalam konteks (mereka memungkinkan identifikasi dari penempatan perubahan jika nomor baris telah berubah).
Perkakas yang digunakan untuk menerapkan modifikasi dalam berkas dinamakan patch. Perkakas yang membuatnya disebut diff, dan berikut ini cara menggunakannya:
$ diff -u file.old file.new >file.patch
Berkas file.patch berisi instruksi untuk mengganti isi dari file.old ke file.new. Kita dapat mengirimkannya pada seseorang, yang dapat menggunakannya untuk membuat ulang file.new dari dua lainnya dengan cara seperti ini:
$ patch -p0 file.old <file.patch
Berkas file.old sekarang identik dengan file.new.
In practice, most software is 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 salsa.debian.org 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.

1.3.2.4. 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, (Bab 7, Memecahkan Masalah dan Menemukan Informasi yang Relevan discusses this in greater detail).
Tidak hanya pengguna membantu mereka (dan lainnya) dalam isu teknis yang berakibat langsung pada mereka, mereka juga mendiskusikan cara terbaik berkontribusi pada proyek Debian, dan membantu meneruskannya — diskusi yang seringkali menghasilkan saran untuk perbaikan.
Karena Debian tidak mengeluarkan dana untuk kampanye promosi, pengguna memiliki peran penting dalam hal difusi, memastikan kehebatan Debian melalui mulut-ke-mulut.
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. Tim dan Sub-Proyek

Debian dikelola dengan konsep sumber paket, dengan setiap pengelola atau sekelompok pengelola. Banyak karya yang lambat laun bermunculan, memastikan administrasi dari infrastruktur, pengelolaan pekerjaan yang tidak spesifik pada paket tertentu (penjaminan kualitas, Debian Policy, installer, dll.), dengan tim terbaru tumbuh di sekitar sub-proyek.

1.3.3.1. Sub-Proyek Debian Saat Ini

Menuju Debian milik mereka masing-masing! Sebuah sub-proyek adalah kelompok relawan yang tertarik mengadaptasi Debian untuk kebutuhan tertentu. Selain memilih suatu sub grup program yang diperuntukkan untuk domain tertentu (pendidikan, kesehatan, pembuatan multimedia, dll.), sub proyek juga terlibat dalam meningkatkan paket-paket yang ada saat ini, pemaketan perangkat lunak yang kurang, adaptasi installer, membuat dokumentasi spesifik, dan masih banyak lagi.
Berikut ini adalah beberapa sub-proyek pilihan yang ada saat ini:
  • 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, oleh Andreas Tille, didedikasikan untuk bidang medis;
  • Debian Multimedia yang berkaitan dengan karya multimedia dan audio;
  • Debian GIS yang mengurus aplikasi-aplikasi dan para pengguna Sistem Informasi Geografis;
  • 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.

1.3.3.2. Tim Administratif

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 (ftp-master.debian.org).
Mereka juga harus memverifikasi lisensi dari semua paket baru untuk memastikan bahwa Debian dapat mendistribusikan mereka, sebelum memasukkan mereka dalam korpus paket saat ini. Saat seorang pengembang ingin menghapus sebuah paket, mereka mengungkapkan masalah ini pada tim melalui sistem pelacakan kutu dan "pseudo-package" di ftp.debian.org.
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 mengelola server milis. Mereka membuat milis baru, mengelola bounces (email yang gagal terkirim), dan mengelola filter spam (email yang tak diinginkan dalam jumlah banyak).
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. Tim Pengembang, Tim Transversal

Tidak seperti tim administratif, tim pengembang relatif lebih terbuka, bahkan pada kontributor luar. Bahkan jika Debian tidak memiliki lokasi untuk membuat perangkat lunak, proyek Debian membutuhkan program spesifik untuk memenuhi tujuannya. Tentu, dikembangkan di bawah lisensi perangkat lunak bebas, perkakas ini menggunakan metode yang sudah terbukti di dalam dunia perangkat lunak bebas.
Debian telah mengembangkan perangkat lunak serderhana dengan versinya sendiri, namun beberapa program telah mendapat peran penting, dan kemasyhurannya telah melampaui batasan proyek. Contoh yang baik adalah dpkg, program pengelola paket Debian (pada praktiknya, dpkg merupakan kependekan dari Debian PacKaGe, dan biasanya diucapkan sebagai "dee-package"), dan apt, perkakas untuk memasang secara otomatis paket Debian berikut dengan kebergantungannya, yang menjamin konsistensi sistem setelah pemutakhiran (apt merupakan kependekan dari Advanced Package Tool). Namun timnya jauh lebih kecil, karena kemampuan pemrograman tingkat tinggi yang dibutuhkan untuk memahami secara keseluruhan operasi-operasi dari program jenis ini.
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.
Tim program debian-cd (yang sangat kecil) memiliki obyektif yang lebih sederhana. Banyak kontributor "kecil" bertanggung jawab pada aristekturnya masing-masing, karena pengembang utama tidak bisa mengetahui semua hingga detailnya, atau cara persisnya bagaimana memulai pemasang dari CD-ROM.
Banyak tim harus berkolaborasi dengan yang lainnya dalam melakukan pemaketan: mencoba, sebagai contoh, memastikan kualitas pada semua tingkatan dari proyek Debian. milis mengembangkan Debian Policy berdasarkan proposal dari berbagai tempat. Tim ini bertanggung jawab untuk setiap arsitektur () meng-compile semua paket, mengadaptasi mereka pada arsitektur tertentu, jika dibutuhkan.
Tim lain yang mengelola paket paling penting agar dapat memastikan pemeliharaan tanpa menempatkan beban yang terlalu berat hanya pada seseorang; hal ini terjadi pada pustaka C dan , compiler C pada , atau Xorg pada (grup ini dikenal juga sebagai X Strike Force).