Re: Some questions to the release manager
On Mon, 21 Jan 2002, Adrian Bunk wrote:
> 1. It's not predictable when packages will be removed from testing
> Packages with RC bugs like armagetron
In case of games I have a real clear opinion: If people want to have fun
they could spens some time to fix bugs before. If they do not want to
work before they should not whine about missing games.
> or elastic
This is another case because some other things might depend from it (not
> are removed without any warning at more or less random time.
But no warnig is not good in any case.
> It will IMHO harm Debian as a whole
> when popular applications will be missing from the next stable release
> without a good reason (some users will say: "What, you have over 5000
> packages but this popular application is not in your stable
Removing packages temporarily from testing because of RC bugs is in my
opinion th eright way to increase preasure on developers to care for
their packages. But they should be warned.
When I heard ajt's talk in Bordeaux 2000 about package pools it was Dwarf
who was the first who asked the same question which caused me to raise my
Will packages with RC bugs be automatically removed from testing?
The answer was "No" and the reason for this was acceptable. But in my
opinion it is necessary to move packages back to unstable if it has
a "long standing" RC bug. We just have to define what we call "long
> 2. We try to get non-frozen packages in a releasable state
> E.g. boot-floppies depend on _many_ non-base packages - and all of these
> non-base packages are non-frozen and a new upstream version of any of
> these packages might break boot-floppies (see e.g. #127405) and for other
> standard+tasks packages themselves it's quite usual that new upstream
> versions get uploaded. I see a big problem in this "get it bug-free before
> it gets frozen" approach because in practice this means we try to get a
> moving target bug-free.
In my opinion we have to freeze all packages boot-floppies depend from.
But perhaps there are technical problems which I do not see ...
> 3. It seems the divided freeze doesn't work as expected
> My personal impression is that it doesn't work to freeze parts of the
> distribution doesn't work in the sense that it costs more time - while
> it's hard to get one part of the distribution completely in a releasable
> state the rest of the distribution stays unfrozen and new upstream
> versions introduce new bugs in the unfrozen packages.
We have to find out the set of dependent packages which potentially prevent
boot-floppies from becoming stable. Freezing all this might help here.