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.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

PERKAKAS Basisdata Pengembang

Debian has a database including all developers registered with the project, and their relevant information (address, telephone, geographical coordinates such as longitude and latitude, etc.). Some of the information (first and last name, country, username within the project, IRC username, GnuPG key, etc.) is public and available on the Web.

→ https://db.debian.org/

Koordinat geografis memungkinkan pembuatan peta yang berisi lokasi para pengembang di seluruh belahan dunia. Debian sungguh merupakan sebuah proyek internasional: Para pengembang Debian bisa ditemukan di seluruh benua, walau mayoritas berada di "Barat".

Gambar 1.1. Distribusi pengembang Debian di seluruh dunia

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.

→ https://www.debian.org/doc/debian-policy/

KEMBALI KE DASAR Pemeliharaan paket, pekerjaan pengembang

Pemeliharaan paket pertama-tama membutuhkan sebuah program “packaging”. Secara khusus hal ini berarti mendefinisikan arti dari instalasi, sehingga saat ter-install, program ini akan beroperasi dan memenuhi semua peraturan dari proyek Debian. Hasil dari pemaketan disimpan dalam sebuah berkas .deb . Instalasi program yang efektif selanjutnya tidak akan membutuhkan apa-apa selain dari hanya mengekstrak arsip terkompresi ini dan mengeksekusi beberapa script pre-instalasi atau post-instalasi yang ada.

Setelah fase awal ini, siklus pemeliharaan sesungguhnya baru saja dimulai: persiapan dari pemutakhiran untuk mengikuti versi terakhir dari Debian Policy, memperbaiki bug yang dilaporkan pengguna, pemasukan versi “upstream” baru dari program, yang secara alami berlanjut untuk mengembangkan secara simultan (contoh: pada waktu pemaketan awal, versi program adalah 1.2.3. Setelah beberapa bulan pengembangan, penulis awal merilis versi stabil baru, dengan nomor versi 1.4.0. Pada titik ini, Debian maintainer harus memperbaharui paket, sehingga pengguna dapat memanfaatkan keuntungan dari versi stabil terbaru).

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:

→ https://bugs.debian.org/debian-policy

KOMUNITAS Proses penyuntingan Kebijakan

Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, a discussion begins on the debian-policy@lists.debian.org mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.

DEBIAN POLICY Dokumentasi

Dokumentasi dari setiap paket disimpan di dalam /usr/share/doc/package/. Direktori ini seringkali berisi berkas README.Debian yang mendeskripsikan pengaturan spesifik-Debian yang dibuat oleh pengelola paket. Sehingga cukup bijak untuk membaca berkas ini sebelum melakukan perubahan konfigurasi dengan mempelajari pengalaman pengelola paket. Kita juga dapat menemukan berkas changelog.Debian.gz yang mendeskripsikan perubahan yang dibuat dari satu versi ke versi selanjutnya oleh pengelola Debian. Tidak perlu bingung dengan changelog.gz (atau yang serupa), yang mendeskripsikan perubahan yang dibuat oleh pengembang upstream. Berkas copyright termasuk informasi mengenai penulis dan lisensi perangkat lunak. Akhirnya, kita juga dapat menemukan berkas dengan nama NEWS.Debian.gz, yang memungkinkan pengembang Debian untuk mengkomunikasikan informasi penting terkait pemutakhiran (jika apt-listchanges digunakan, pesan yang ditampilkan otomatis oleh apt). Semua berkas selain ini merupakan berkas spesifik untuk perangkat lunak. Kami ingin menunjukkan khususnya examples sub-directory, yang seringkali berisi contoh dari berkas konfigurasi.

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:

→ http://www.debian.org/devel/constitution.en.html

KULTUR Flamewar, diskusi yang memercikkan api (memancing emosi)

“Flamewar” adalah debat yang terlalu berapi-api, yang seringkali berakhir dengan pertengkaran antara satu pihak dengan pihak lainnya usai kedua pihak telah kehabisan argumentasi yang masuk akal. Beberapa tema tertentu sebenarnya lebih merupakan polemik bagi lainnya (contoh, pilihan penyunting teks, “Anda lebih suka vi atau emacs?”). Permasalahan ini seringkali memprovokasi hingga datang begitu cepat surel yang masuk akibat begitu banyaknya orang beserta pendapatnya dan sifat pertanyaan yang begitu personal.

Tidak ada yang berguna dari diskusi semacam ini; tetap jaga diri dari debat seperti ini, dan lewati saja isinya. Membaca lengkap akan sangat menghabiskan waktu.

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”.

KULTUR Meritokrasi, pemerintahan pengetahuan

Meritokrasi adalah bentuk pemerintahan yang mempercayakan kekuasaan kepada mereka yang berkontribusi paling hebat. Bagi Debian, merit adalah tolok ukur kompetensi, yang diukur dari observasi rekam jejak oleh mereka di dalam proyek (Stefano Zacchiroli, pemimpin proyek Debian saat ini, berbicara soal “do-ocracy”, yang berarti “kekuatan bagi mereka yang menyelesaikan”. Keberadaan sederhana mereka membuktikan tingkat kompetensi; pencapaian mereka secara umum dengan perangkat lunak bebas, dengan kode sumber yang tersedia, yang dapat dengan mudah di-review oleh olah orang lain untuk menilai kualitas mereka.

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.

KOMUNITAS Integrasi dari pengelola baru (new maintainers)

Tim yang bertanggung jawab untuk menerima pengembang baru adalah tim yang paling sering dikritik. Seseorang harus mengakui bahwa, selama bertahun-tahun, proyek Debian semakin menuntut pengembang yang dapat diterima. Beberapa orang melihat ketidakadilan dalam proses itu, namun kami harus mengakui bahwa yang awalnya hanya tantangan kecil bisa menjadi rumit dalam komunitas dengan jumlah lebih dari 1,000 orang, saat harus memastikan kualitas dan integritas dari yang semua Debian hasilkan bagi penggunanya.

Lebih lanjut, prosedur penerimaan disimpulkan dengan review dari tim kecil terhadap kandidat, Debian Account Managers. Manager ini secara khusus terekspos untuk dikritik, karena mereka yang memiliki keputusan akhir dari penerimaan atau penolakan relawan dalam komunitas pengembang Debian. Pada praktiknya, terkadang mereka harus menunda proses penerimaan seseorang hingga akhirnya mereka selesai mepelajari bagaimana cara kerja dari proyek. Tentunya seseorang dapat berkontribusi ke Debian tanpa diterima secara resmi sebagai pengembang Debian dengan cara disponsori oleh pengembang saat ini.

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.

Debian BTS (Bug Tracking System/Sistem Pelacakan Kutu) menjadi sampul dari proyek. Bagian publik dari antarmuka web memungkinkan pengguna melihat semua kutu yang dilaporkan, dengan pilihan untuk menampilkan kutu berdasarkan beragam kriteria, seperti: paket yang terkena efek, severity, status, alamat dari pelapor, alamat dari pengelola, tag, dll. Juga memungkinkan untuk menjelajahi daftar historikal lengkap semua diskusi dari setiap kutu.

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 12345@bugs.debian.org 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 12345-done@bugs.debian.org (sebuah kutu diungkapkan saat masalah indikasi dipecahkan atau tidak lagi relevan). Kutu baru dilaporkan dengan mengirimkan surel ke submit@bugs.debian.org berdasarkan format tertentu yang mengidentifikasi paket yang dipertanyakan. Alamat control@bugs.debian.org 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

→ https://www.debian.org/Bugs/

KOSAKATA Tingkat severity dari bug

Severity dari bug secara formal menandakan tingkat pada masalah yang terindikasi. Dilihat secara efektivitas, tidak semua kutu sama penting; contohnya, kesalahan pengetikan pada halaman manual tidak dapat dibandingkan dengan kerawanan keamanan dalam perangkat lunak server.

Debian uses an extended scale to describe the severity of a bug. Each level is defined precisely in order to facilitate the selection thereof.

→ https://www.debian.org/Bugs/Developer#severities

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.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

KEMBALI KE DASAR Apa itu i18n dan l10n?

“i18n” dan “l10n” adalah kependekan dari kata “internationalization” dan “localization”, dengan cara mengambil huruf awal dan huruf akhir dari setiap kalimat, sementara angka menunjukkan jumlah huruf yang berada di antaranya.

Untuk “internationalize” sebuah program terdiri dari modifikasi sehingga dapat diterjemahkan (lokalisasi). Hal ini meliputi menulis ulang program parsial dengan cara bekerja dalam satu bahasa agar dapat terbuka pada semua bahasa.

Untuk “localize” program berarti terdiri dari menerjemahkan naskah asli (seringnya dalam Inggris) ke bahasa lain. Untuk melakukan ini, harus sudah di-internasionalisasi.

Ringkasnya, internasionalisasi menyiapkan perangkat lunak untuk diterjemahkan, yang selanjutnya dieksekusi dengan lokalisasi.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program 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.

TOOL Git, the preferred way to send patches

Git is a version-control system designed for coordinating work among developers and track their changes. It was programmed by Linus Torvalds (the creator of Linux) in 2005 to coordinate the development of the Linux kernel.

Nowadays, it is common to send patches using Git. Many Debian projects using Git can be found on https://salsa.debian.org/.

To send a patch using Git, you must download a copy of the repository, make the fixes, add them to the stage area, commit the changes, upload your changes, and request the maintainer to accept your changes. It is beyond the scope of this book to provide a detailed explanation about Git, for that you can refer to the Pro Git book (https://git-scm.com/book/).

Below is an example of the commands needed to submit a patch to this book. You can use GitLab's web interface to make the pull request; another option is to use the command git request-pull and send its output to the developers.

$ git clone https://salsa.debian.org/youruser/debian-handbook/
Cloning into 'debian-handbook'...
remote: Enumerating objects: 20838, done.
remote: Counting objects: 100% (20838/20838), done.
remote: Compressing objects: 100% (4510/4510), done.
remote: Total 20838 (delta 16316), reused 20809 (delta 16307)
Receiving objects: 100% (20838/20838), 139.41 MiB | 131.00 KiB/s, done.
Resolving deltas: 100% (16316/16316), done.
Checking out files: 100% (1351/1351), done.
$ editor file
$ git add file
$ git commit -m "Correct typo in chapter 3"
[buster/master ca5a0039] Update chapter 1
 1 file changed, 98 insertions(+), 54 deletions(-)
$ git push
Username for 'https://salsa.debian.org': youruser
Password for 'https://youruser@salsa.debian.org': yourpasswd
Enumerating objects: 96, done.
Counting objects: 100% (96/96), done.
Delta compression using up to 2 threads
Compressing objects: 100% (80/80), done.
Writing objects: 100% (80/80), 456.23 KiB | 3.83 MiB/s, done.
Total 80 (delta 59), reused 2 (delta 0)
To https://salsa.debian.org/youruser/debian-handbook.git/
   18e0e26c..ca5a0039  buster/master -> buster/master

It is a good practice to review the changes before executing git add. You can execute git diff for that. It will open the default pager (usually less) to display the differences. The lines starting with - are the removed lines, whereas the lines starting with + show added lines.

1.3.2.4. Other ways of contributing

Semua mekanisme ini didorong oleh perilaku pengguna. Jauh dari keadaan terisolasi, mereka merupakan komunitas di mana pertukaran sungguh terjadi. Kami sangat menghargai aktivitas impresif dari pengguna dalam milis diskusi debian-user@lists.debian.org (Bab 7, Memecahkan Masalah dan Menemukan Informasi yang Relevan mendiskusikan hal ini lebih 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:

→ https://www.debian.org/events/material

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.

KOSAKATA Sub-proyek dan distribusi turunan

Proses pengembangan distribusi turunan terdiri dari memulai dengan versi tertentu Debian dan membuat beberapa modifikasi. Infrastruktur yang digunakan untuk pekerjaan ini tidak menggunakan infrastruktur proyek Debian. Sebenarnya tidak ada kebijakan untuk mengkontribusikan perbaikan. Perbedaan ini menjelaskan bagaimana distribusi derivatif dapat “bercabang” dari asalnya, dan mengapa mereka harus sinkronisasi ulang secara teratur dengan sumbernya agar dapat mengambil keuntungan dari perbaikan yang dibuat di upstream.

Di sisi lain, sub-proyek tidak dapat bercabang, karena semua pekerjaan yang dibuat adalah secara langsung memperbaiki Debian agar dapat mencapai tujuan tertentu.

Distribusi derivatif dari Debian yang paling terkenal, tanpa perlu ragu, adalah Ubuntu, namun ada banyak. Lihat Lampiran A, Distro Turunan untuk mempelajari mengenai kekhasan dan posisi mereka dalam hubungannya dengan Debian.

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

Mayoritas tim administratif relatif dekat dan perekrutan hanya dilakukan dengan cara kooptasi. Cara terbaik untuk bergabung adalah dengan membantu secara cerdas anggota saat ini, menunjukkan bahwa Anda telah mengerti objektif dan metoda operasi.

ftpmasters secara bertanggung jawab dari arsip ofisial paket Debian. Mereka mengelola program yang menerima paket dikirim oleh pengembang dan secara otomatis menyimpannya, setelah beberapa pemeriksaan pada server reference (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.

KOSAKATA pseudo-package, perkakas monitoring

Sistem pelacakan bug, awalnya didesain untuk mengasosiasikan laporan bug dengan paket Debian, telah terbukti sangat praktis untuk mengelola hal lain: daftar masalah yang perlu dipecahkan atau tugas untuk dikelola tanpa harus terkait ke paket Debian tertentu. "pseudo-packages" memungkinkan suatu tim menggunakan sistem pelacakan bug tanpa harus mengasosiasikan paket sesungguhnya dengan timnya. Semuanya lantas dapat melaporkan isu yang perlu ditangani. Sebagai contoh, BTS memiliki entri ftp.debian.org untuk melaporkan dan melacak masalah pada arsip paket resmi atau sekedar meminta penghapusan sebuah paket. Mirip itu, pseudo-package www.debian.org mengacu ke kesalahan-kesalahan pada situs web Debian dan lists.debian.org mengumpulkan semua masalah terkait dengan milis.

TOOL GitLab, Git repository hosting and much more

A GitLab instance, known as salsa.debian.org, is used by Debian to host the Git packaging repositories but this software offers much more than simple hosting and Debian contributors have been quick to leverage the continuous integration features (running tests, or even building packages, on each push). Debian contributors also benefit from a cleaner contribution workflow thanks the well understood merge request process (similar to GitHub's pull requests).

GitLab replaced FusionForge (which was running on a service known as alioth.debian.org) for collaborative package maintainance. This service is administered by Alexander Wirt, Bastian Blank and Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

Tim Administrator Sistem Debian (DSA) (debian-admin@lists.debian.org), seperti yang diharapkan, bertanggung jawab untuk administrasi sistem dari banyak server digunakan oleh proyek. Mereka memastikan fungsi optimal dari semua layanan dasar (DNS, Web, e-mail, shell, dll), memasang perangkat lunak yang diminta oleh para pengembang Debian, dan mengambil semua tindakan pencegahan dalam hal keamanan.

→ https://dsa.debian.org

ALAT Pelacak Paket Debian

Ini adalah salah satu kreasi Raphaël. Ide dasarnya adalah, bagi sebuah paket, untuk mensentralisasi informasi sebanyak mungkin pada satu halaman. Jadi, seseorang dapat dengan cepat memeriksa status program, mengidentifikasi tugas yang perlu diselesaikan, dan menawarkan bantuan. Inilah sebabnya mengapa halaman ini mengumpulkan semua statistik bug, versi yang tersedia di setiap distribusi, kemajuan sebuah paket di distribusi Testing, status terjemahan deskripsi dan template debconf, kemungkinan ketersediaan versi hulu baru, pemberitahuan ketidakpatuhan dengan versi terbaru dari Kebijakan Debian, informasi tentang pengelola, dan informasi lainnya yang ingin disertakan oleh pemeliharanya.

→ https://tracker.debian.org/

Sebuah layanan langganan surel melengkapi tampilan antarmuka web ini. Secara otomatis ini mengirimkan informasi yang dipilih berikut ke milis: bug dan diskusi terkait, ketersediaan dari versi baru pada server Debian, terjemahan baru siap untuk diperiksa, dll.

Advanced users can, thus, follow all of this information closely and even contribute to the project, once they have got a good enough understanding of how it works.

Tampilan antarmuka web lainnya, dikenal sebagai Debian Developer's Packages Overview (DDPO), menyediakan bagi setiap pengembang sinopsis dari status semua paket Debian yang ada di bawah kendali mereka.

→ http://qa.debian.org/developer.php

Kedua situs adalah alat yang dikembangkan dan dikelola oleh grup yang bertanggung jawab untuk jaminan kualitas dalam Debian (dikenal sebagai Debian QA).

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.

KULTUR Git

Git adalah alat untuk kerja kolaborasi pada beberapa berkas, sambil mempertahankan sejarah modifikasi. Berkas yang dimaksud umumnya adalah berkas teks, seperti misalnya kode sumber program. Jika beberapa orang bekerja bersama-sama pada berkas yang sama, git hanya dapat menggabungkan perubahan-perubahan yang dibuat jika mereka dibuat untuk bagian-bagian yang berbeda dari file. Bila tidak, "konflik" ini harus diselesaikan secara manual.

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it's called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can add (git add) the selected files for inclusion in a new entry in the repository, with the added files it can create a new entry in the versions history (git commit), it can update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

Git membuatnya mudah untuk menangani beberapa versi bersamaan proyek dalam pengembangan tanpa mereka mengganggu satu sama lain. Versi ini disebut branch. Metafora pohon ini cukup akurat, karena program ini awalnya dikembangkan pada batang umum. Ketika sebuah tonggak telah tercapai (seperti versi 1.0), pengembangan terus pada dua cabang: cabang pengembangan mempersiapkan rilis besar berikutnya, dan cabang pemeliharaan mengelola pembaruan dan perbaikan untuk versi 1.0.

Git adalah, saat ini, sistem kendali versi yang paling populer tetapi bukan satu-satunya. Secara historis, CVS (Concurrent versi sistem) adalah alat pertama yang digunakan secara luas tetapi berbagai keterbatasannya memberikan kontribusi terhadap munculnya alternatif gratis yang lebih modern. Ini termasuk, terutama, subversion (svn), git, bazaar (bzr), dan mercurial (hg).

→ http://www.nongnu.org/cvs/

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

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.

Tim yang paling penting mungkin adalah tim program instalasi Debian, debian-installer, yang telah menyelesaikan begitu banyak pekerjaan monumental dari awal konsepnya di tahun 2001. Begitu banyak kontributor dibutuhkan, karena sulitnya menulis satu program untuk memasang Debian pada lusinan arsitektur yang berbeda. Setiap arsitektur memiliki mekanisme booting dan bootloadernya sendiri-sendiri. Semua pekerjaan ini dikoordinasikan dalam milis debian-boot@lists.debian.org, di bawah pimpinan Otavio Salvador dan Joey Hess.

→ http://www.debian.org/devel/debian-installer/

→ http://kitenet.net/~joey/blog/entry/d-i_retrospective/

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: debian-qa@lists.debian.org mencoba, sebagai contoh, memastikan kualitas pada semua tingkatan dari proyek Debian. debian-policy@lists.debian.org milis mengembangkan Debian Policy berdasarkan proposal dari berbagai tempat. Tim ini bertanggung jawab untuk setiap arsitektur (debian-architecture@lists.debian.org) 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 debian-glibc@lists.debian.org, compiler C pada debian-gcc@lists.debian.org, atau Xorg pada debian-x@lists.debian.org (grup ini dikenal juga sebagai X Strike Force).