Hi, On Fri, 30 Aug 2019, Alexander Wirt wrote: > > We're not speaking of crap software, we're just speaking of software that > > can't be maintained multiple years by backports of security patches, where > > we get fixes only with new upstream versions (mixed with new features). > I don't want to draw that line, someone would have decide if the software is > just crap, the maintainer too lazy or if its really fast pacing. Wordpress is > an example of a software that should really be supported within stable. If > not its just crap. > > Imho we should have packages in testing that will not be part of the next > release. And we don't want any form of automated migrations. Full stop. > People should build and *test* their packages against stable. I don't know if I'm expressing myself very badly, but there's clearly a misunderstanding. Right now there is no "stable" release where you would build packages for bullseye-backports. If you keep the same logic of building next release packages against the current release, then for bullseye-backports that would mean building packages from unstable in a testing environment. There's usually no point in doing that because both distributions are very close. The way to go from one one to the next is to go through britney. To me it made sense because the split between testing and bullseye-backports would follow the same logic as the split between stable and stable-backports: in the former repositories you have versions of packages that can be maintained over a long time, in the latter you have either versions of such packages that can't be supported over multiple years or packages for which there are no single version that can be supported multiple years (e.g. because they are too complex and upstream supports only the latest release). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Attachment:
signature.asc
Description: PGP signature