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
signature.asc
Description: PGP signature
