Getting Started as a Contributor

In order to be able to effectively participate as a contributor to the Debian LTS Team, several things are required. It is necessary to know where the work happens, and to have an appropriately configured work environment.

The things documented in this page are applicable to all contributors, regardless of sponsorship status. Contributors performing work sponsored by Freexian also have some additional requirements, which are pointed out at the appropriate points below.

After developing an understanding of where the work happens and then setting up the work environment, it will be time to find some work to do.

Where the Work Happens

The majority of the work of the Debian LTS Team takes place in ways which are visible to the general public.

For example, bugs reports against Debian packages are filed in the Debian bug tracking system, which is accessible via a web browser and to which messages can be posted via email without any requirement for account registration.

LTS-specific tasks and projects are located in the LTS group on Debian’s Salsa project hosting service and read access to these projects is public. Additionally, much LTS work also takes place in individual maintainer repositories also hosted on Salsa, which are likewise publicly accessible. Though in general, participating in these projects (e.g., by making comments on issues or submitting MRs) does require an account. There is also more information on Salsa for those who are interested in understanding Debian’s project hosting service.

Collaborating With the Team

The means by which the team collaborates, including various communication channels are detailed in Collaborating with the Team.

Setting up the Work Environment

This section describes various steps which a contributor must take in order to prepare a work environment for making contributions to the Debian LTS Team. Note that not all of these steps may be necessary, especially for contributors seeking to make specific targeted contributions. In that case you might simply browse this page to become familiar with its contents and then return as needed for information on specific items. If you are reading this document because you are already making general contributions or because that is your intent, then it is best to perform all of the steps documented here.

Salsa

Action

Create an account on Sasla.

Explanation

As described in the introduction above, the Debian LTS Team does much of its work in projects located in the LTS group on Debian’s Salsa project hosting service. While those and most other projects can be browsed without being authenticated by the Salsa service, making comments, creating MRs, and write access to code repositories all require an account.

Test Environment

Action

Create an appropriate environment for testing patches and package updates by Installing LTS the Debian release for which you will be testing packages (see the explanation section below for a discussion of possible virtualization approaches).

Explanation

Even if you are not preparing package updates yourself, you may find that you want to help by testing package updates or patches prepared by others. While it may possible to do this type of testing directly on your own system (assuming it is running the corresponding Debian release), this generally not the recommended approach.

Instead, because of the risks involved with testing patches and packages which may have unresolved issues and because it is a good practice to isolate packages under test from potential interference or disruption by system-level customizations, the better approach is to create an installation specifically for testing. There are a wide variety of approaches which could apply here, including a chroot environment. However, the discussion of chroots is reserved for setting up a package build environment. The recommendation given here for a suitable testing environment is to use a virtualization solution (such as libvirt, Qemu, VirtualBox, or another system virtualization solution).

A complete system installation in a virtualized environment provides the best flexbility for being able to test graphical packages (which can be difficult in a chroot), to test packages which require rebooting (e.g., Linux kernel and bootloader), to test packages which could potentially compromise system security if misconfigured or misused (e.g., sudo and su), and so on.

A container-based solution (several of which are discussed on the system virtualization wiki page) may also be a good choice, depending on your particular circumstances.

Package Build Environment

Action

Create an appropriate environment for building package updates.

Explanation

LTS package updates must be built in the same way as any other Debian package, whether that package is destined for the experimental distribution, unstable, or the oldest supported stable release. A look at the Debian Developer’s Reference, or any of the variety of other developer-centric manuals which Debian maintains will reveal a thoroughgoing emphasis on package builds being repeatable. This repeatability is directly tied to the building of packages in an appropriate environment.

If you already build Debian packages for other purposes (perhaps as a Debian Developer maintaining packages in the unstable distribution), then you likley already have a package building workflow that works well for your specific needs. In that case, it is sufficient to add an environment (chroot, container, etc) to support building for the desired target distribution (e.g., buster, bullseye, etc.).

Quoting from the section Preparing packages to address security issues in the Debian Developer’s Reference:

Build the package on a clean system which only has packages installed from the distribution you are building for. If you do not have such a system yourself, you can use a debian.org machine (see Debian machines) or setup a chroot (see pbuilder and debootstrap).

Security Tracker Repository

Action

Clone a copy of the Debian security tracker repository.

Attention

Frexian-sponsored contributors require a collection of multiple repositories which will include a copy of the security tracker. If you are a Freexian-sponsored contributor then follow the instructions located here. If you are not a Freexian-sponsored contributor then the link will be inaccessible to you. TODO: update the link

Explanation

While many tasks will in fact be possible without requiring a complete clone of the security tracker repository, there are some tasks (e.g., actually claiming a package to work on, updating notes on a package, and CVE triage) which require a local working copy of the security tracker. Note that the security tracker repository is enormous and has a history going back extremely far. If you perform a simple git clone operation, then be prepared to wait as long as 2 hours for the clone operation to complete (even with a fast connection it takes this long because of the deltas that must be computed) and for it consume approximately 2 GB of storage.

Depending on the specific task or tasks you intend to work on, it is advisable to prune the history during the clone operation; the --shallow-since=<date> and --depth <depth> options provide ways to accomplish this. Consult git-clone(1) for further details about their usage.

Next Steps

After developing an understanding of where the work happens and then setting up the work environment, it’s time to find some work to do.