Re: Why are backports of Squeeze packages in etch-backports?

[Gerfried Fuchs <rhonda@deb.at>]

* Bernhard R. Link <brlink@debian.org> [2009-03-09 17:51:48 CET]:
> * Micha Lenk <micha@lenk.info> [090309 09:56]:
> > Then, can we agree on such a new policy *now*, so we can reference to a
> > certain mail on backports-users once squeeze is released and packages
> > from squeeze+1 get uploaded to bpo? This could avoid that we get the
> > same (of course valid) excuse again in the future. We can then finally
> > do what the backports users (me included) expect...
> 
> That leaves the question what backport users actually expect.
> 
> Restricting bpo to packages from the next release would effectively
> freeze ${something}-bpo when ${something} becomes oldstable (thus making
> it practically worthless in my eyes).

 It's not worthless. It still gives people the newer features from the
next release in the (old)stable release, and it still allows having
security updates.

> Restricting to packages that cause no problems with upgrading to the
> next release keeps it more useful, but that might be hard to decide
> automatically.

 I don't see much difference to the above, please explain further what
you mean with this because I can't think of such a case besides a
package not being released with the next release -- but in this case we
are removing packages from backports already to not have to keep
maintaining them solely on backports.

> I'd personally prefer a policy requesting that backports in
> ${oldstable}-bpo must have a upgrade path in ${stable}-bpo.

 Like was pointed out by several people not everyone wants to/plans to
keep tracking a package for always and evermore from backports. IMHO
more often the case is that one does use a package from backports
because it contains a specific feature. When the next release happens
that feature is in the next stable release - and there is no need to
track it anymore through backports. The wish to have official security
support is something that shouldn't be belittled; and even though I try
to track these problems for backports there is not much help in this
area (with a few exceptions, thanks - you know who you are) and we still
have quite some packages with (more or less severe) security issues in
etch-backports and I don't believe that this is going to get much better
for the lenny-backports lifetime.

 I feel extremely uneasy to force people to keep tracking a package from
a service that can't relieable assist its users with updates, might it
be security-related or "just" other bugs that they are bothered with.

 So long,
Rhonda