On Tue, 25 Dec 2018, Dominik George wrote: > 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. We already told you to build your own repo. Please don't mix that with backports. Imho you should start the same way backports started - outside of debian. Prove that it works and integrate into Debian later. Alex
Attachment:
signature.asc
Description: PGP signature