Re: updates in stable do happen
#include <hallo.h>
* Raphael Hertzog [Wed, Apr 11 2007, 08:46:29AM]:
> If we're going to experiment something like that, I think it would have
> to:
> - be a subset of our packages and it should concentrate on applications,
> we should avoid library updates in that section
> - have a policy of continuous updates (new upstream versions of
> applications are always coming in after all)
> - have a policy of manual testing and approval while the packages are
> staging in the "proposed-updates"
> - have some kind of agreement from the maintainers that he's going to
> security support his package in that new section
>
> In the end, this is exactly an officialy integrated "backports.org". :-)
I had something similar in mind. A problem that I see in Debian is the
lack of trust between the people who maintain the software and the ones
who decide which packages go into Frozen or Stable. This strategy is
written down in our official documents, sure, but the outcome of that
actually damages the final product and Debian's reputations when the
release period becomes too long.
Sometimes, when a maintainer thinks that a new upstream release is
worth being pushed into Stable even considering the risks then (s)he
may be right! What is the point of keeping some minor package in
outdated status for two years when it does not have any relevant
reverse-deps and the maintainer assures that the upstream changes do
solve lots of problems that keep annoying the users _for those two years_?
I think we might add some backports.org based shadow branch to our
archive. Maybe called like "backport evaluation branch", where new
backports arrive after a check by some backports approval committee,
having also some monthly or bi-monthly releases that DVD distributors
may add as some extra bonus pack (Debian "CAB" aka Certain Approved
Backports).
Eduard.
--
Fanatismus besteht im Verdoppeln der Anstrengung, wenn das Ziel
vergessen ist.
-- George de Santayana
Reply to: