Re: Maintaining intermediary versions in *-backports
If it is a security fix we should perhaps first upload it and then start a discussion how to deal with the package that needs its security fixed as it perhaps shouldn't have been there in the first place hoping that there is a way to do so that doesn't break something for our users: Security is important and if backports weren't usable for something and weren't important we wouldn't invest this much time in them.
But as a relative outsider who maintains a backport and therefore reads this list my impression is that we could reduce the amount of discussion here by a considerable amount by doing the following changes:
1.) We all know that "backports" were introduced as a way to allow users to profit from new features in a few well-tested packages from testing one has agreed to maintain for the more stable distributions. But I don't see this documented in the rules. We should document that more explicitely there. For example I cannot find the place where they explicitely state that even if a "stable" package inevitably crashes on start-up and nobody seems to update it for years it still is stable that has to be fixed.
In many other places the official rules for backports are quite complete: They make clear that the backporter needs to be willing to do maintain this package from the moment the backport has been make. The users are already informed that backports still are not really supported - and it is also obvious that maintaining backports with loads of dependencies or backports for packages everything depends upon is a lot of work.
2.) The rules explicitely allow for "backporting" a package that hasn't been in testing and tell that one should refer to this list first. Despite that we insist that "backport" means "backport" in the way that what the backport needs to have been in testing first. This policy makes sense: Fix things in stable, if they are broken there. Fix things in testing, if they are broken there and only add things to "backports" after they have been in testing for a while as the user expects backports to only contain packages that are quite well-tested.
Currently the rules hint into a completely different direction. Instead they should make it clear that exceptions from this rule are made only if this *really* is inevitable and that it is unlikely to find a place where this condition is met.
3.) How would a lintian rule look like that prevents us from adding things to backports that aren't part of the testing release? And how hard would it be to add it to lintian? Currently validating if a package is eligible for a backport is too much manual work, is prone to errors and if a think is prone to errors and the rules are interpreted in a way but hint into a different direction it is clear that sooner or later someone will try not to circumvent the rules, but to do the thing they seem to allow. The only thing needed for this to happen is that something makes doing so important enough.
Kind regards,
Gunter.
Reply to: