Re: Some observations regardig the progress towards Debian 3.1
On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
>
> > During the last months, the number of RC bugs of packages in unstable
> > was constant at 700 bugs including 500 RC bugs in packages that are in
> > testing [2].
>
> > Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately
> > this doesn't work: Debian is too big. I might e.g. be able to fix 50
> > easy to fix RC bugs in unstable, but this would be lost in the noise,
> > and wouldn't result in real progress.
>
> > Debian with over 1200 maintainers and over 13000 packages [3] is too big
> > to work in the relatively unstructured way it is currently. Announcing
> > 0-day NMUs isn't sufficient to get a significant number of bugs fixed,
> > it's at least required to organize many bug squashing parties and to
> > work hard to get many people involved in them [4].
>
> Are you planning to organize a bug squashing party, then?
I'm willing to organize bug squashing parties (one is for sure not
enough), but this has to be part of a release plan that seems doable and
that is enforced.
The latest published release plan is quite obsolete.
> > It's often suggested to remove packages (at least from testing) if the
> > maintainer is inactice.
>
> > If a maintainer is MIA, his packages should be orphaned and he should be
> > kicked out of Debian as soon as possible.
>
> > But for a user, it doesn't matter why a package isn't in Debian stable.
> > E.g. I've heard questions why gnuchess isn't in Debian 3.0 .
>
> Do you feel there are reasons why
> <http://bugs.debian.org/release-critical> and the various scripts
> floating around to provide daily RC reports fail to ensure that packages
> people care about are taken care of in spite of the maintainer? What
> methods would you propose to better balance between providing the
> software users need and not distributing packages that are
> embarrassingly buggy?
- frequent bug squashing parties
- faster orphaning of packages of MIA maintainers
> (FWIW, I've never heard of packages being removed from testing on the
> grounds of maintainer inactivity -- only on the grounds of package
> bugginess.)
A MIA maintainer doesn't fix bugs in his packages, and this can lead to
the removal of a package.
It's perhaps nitpicking whom of us is right in this case. ;-)
> > For testing to work good, it's required to have unstable in a good
> > state. Often new so-versions of libraries enter unstable, and e.g. KDE
> > 3.2 might soon go into unstable. If testing should be frozen, it's
> > needed to _freeze unstable_ (IOW: require RM approval for every upload
> > to unstable). This doesn't need to be under a "no new upstream code"
> > policy at the beginning, but at least beta versions, new so-names and
> > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> > be avoided.
>
> Yes, I've actually been pondering whether it wouldn't make sense to try
> to serialize major transitions (such as soname changes), to improve our
> chances of keeping testing both releasable and reasonably up-to-date at
> all times. I've also tried to encourage mini-freezes in cases where
> groups of packages were almost-but-not-quite ready for testing.
>...
After nearly three years of testing, my impression is that the hopes
that testing would be always releasable were never fulfilled.
woody was the first release that started from testing, and there was
much more than half a year between the beginning of the freeze and the
actual release.
Your work of trying to get packages into testing through mini-freezes
is what I called a "Sysyphos task" in my initial mail: As long as the
flood of new upstream versions into unstable isn't stopped, there are
always new problems poping up once the current ones are solved.
You need a freeze at one point (unstable or testing) to get a base where
you can start to fix the remaining problems without new bugs from new
upstream versions.
The choices are:
- freeze testing and start then to backport all the bug fixes and
security fixes from unstable
- freeze unstable and try to get as many packages as possible from
unstable into testing (exactly the work you are currently doing, but
based on a more stable basis)
- freeze unstable and use unstable as a basis
All three choices are doable.
I'd say the first one is most work of the three choices, but these are
only my personal feelings.
> Steve Langasek
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: