Web lists-archives.com

Proposal: Repository for fast-paced package backports




Heisann, alle sammen,

as announced in the recent thread about maintaining, I hereby propose a
repository that allows making “backports” of packages available to users
of the stable distribution, if those packages cannot be maintained in
testing and backported in the usual way. If you are interested in what
lead up to that, please see bug #915050. I will give a short summary of
it here.


Reasons for having a special place for some packages
====================================================

(You may want to skip this part if you are familiar with the situation.)

As all developers know (but passers-by may not), for software to enter
the Debian archive, it is always uploaded to the unstable distribution,
then migrates to testing (hopefully ;)), which is at some point snapshot
and made the new stable release. From there on, maintainers have two
obligations: Firstly, keep the package in stable good and secure, e.g.
by uploading security fixes for it once they become available upstream,
or even backport fixes themselves. Secondly, provide the package in
unstable with updates and ensure its migration, to keep it ready for the
next stable release.

Now, for some software packages, this process is problematic, because
upstream may have another idea about software lifecycles. Concerning the
GitLab example, upstream provides security fixes for three months for
their stable releases. Backporting fixes from newer versions is very
hard or impossible because the massive amounts of changes to the
software in every new versions. This is something that also affects
other packages, like Mozilla Firefox, which has a firefox package in
unstable, and a separate firefox-esr package, with the ESR version of
Firefox. Only the latter migrates to testing.

Users of Debian honour it for its stability, but as an agile software
lifecycle is adapted by more and more very popular software packages,
not being able to install these packages in the trusted, well-known
fashion through the official apt repositories is becoming more and more
of a drawback.

It can easily be assumed that the normal release and maintenance cycle
of Debian stable will not change, which is very good, so we should find
a way to still provide such software as described above to users.


Why backports is not enough
===========================

This also is well-known, but for completeness: Formal backports in
stable-backports are required to be direct backports from testing, and
are a stepping stone within the upgrade from stable to stable+1. Thus, a
version of a package that is not in testing can never be in
stable-backports.


Name of the new repository
==========================

In the past, the name “volatile” was used for a similar repository, but
with a different scope (limited to data packages for things like virus
scanners). I will thus use the working title volatile throughout this
proposal, although this may change.

Other ideas: fastlane, unsupported

(Please feel free to add other ideas.)


Requirements for a package to go into stable-volatile
=====================================================

The new volatile proposal is not intended to ease life for package
maintainers who want to bypass the migration and QA requirements of the
regular stable lifecycle, so special need must be taken to ensure only
packages that need it go into volatile. I want to summarise the
requirements like so:

 - The package must be maintained in unstable, like every other package.
 - The package must not be in testing, and care must be taken for the
   package not to migrate to testing.
 - Regular maintenance for the lifetime of stable must be impossible
   or unnecessarily hard, and this requirement should be assessed in
   a verifiable manner, e.g. referring to upstream’s lifecycle model.
 - There must be notable need for the package. Like for backports, user
   requests might be an indicator.
 - Should the package be removed from unstable, it must also be removed
   from volatile.
 - Should the package begin to migrate to testing again, it must
   be moved to stable-backports.

Before starting to maintain a volatile package, the maintainer shall
seek consent (or doubt) on debian-devel.


Building packages and package dependencies
==========================================

Packages for volatile are built the same way as formal backports, only
that the source is taken from unstable rather than testing. In
particular:

 - Changes shall be kept as small as possible.
 - The package is rebuilt against stable.
 - The package may depend on packages in stable, stable-backports or stable-volatile.

Dependencies on other packages in volatile should be avoided if
possible. Especially, dependencies of the package that also need
backporting must not be added to volatile just because they are
dependencies — every dependency that is needed to be backported to
support the volatile package must be considered on its own and in all
but unprobable edge cases be maintained as a formal backport. Obviously,
the unprobable edge case occurs when the package depends on another
package that also fully qualifies for volatile, as described above.


Versions of packages in volatile
================================

I am not yet certain about this. As stressed before, volatile should be
an extension of backports, so starting with the well-known backports
suffix ~bpoN seems reasonable. I’d even say this is enough, as a package
is never both in volatile and backports, and if maintenance changes to
the regular lifecycle, it can easily be moved to backports.


Responsibility and location of the repository
=============================================

I propose to add the volatile repository next to the backports
repository, and treat it as part of backports. This should not impose
new workload on the backports ftp-masters, so this needs people who
volunteer to do the extra work. It should, however, be not too much of a
workload anyway, as the number of packages qualifying for volatile is
quite limited. (I do volunteer for the backports team, not only for my
own proposal, but also in general.)

This implies that new binary uploads to volatile have to undergo the
same NEW queue as backports.


volatile repositories for other distributions
=============================================

You guessed it: Same as for backports, but in green ;).


Technical requirements
======================

Apart from the new section in the repository, care needs to be taken to
ensure removal from volatile if a package moves to -backports again. The
mechanisms used for decrufting experimental might apply.


Implications for the situation at hand (gitlab)
===============================================

As there were quite a few concerns raised (some of which I share, and
some I don’t): Of course, if a software intended for volatile has a ton
of dependencies (intended to go into backports), all backports rules and
powers of the ftp-masters apply. Repeating myself: volatile is not meant
to ease the life of maintainers.



I ask the community, the backports team and the release team for their opinions.

Cheers, ha det bra,
Nik

Attachment: signature.asc
Description: PGP signature