Re: Some observations regardig the progress towards Debian 3.1
On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> Today, it's only 17 days until the officially announced "aggressive goal"
> for the release of Debian 3.1 . That's a date many users know about,
> but I don't see any real progress towards Debian 3.1 during the last
I suppose you don't subscribe to debian-boot or debian-devel-announce, then?
> 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.
So instead, we have a system where people take individual (or small group)
responsibility for a particular piece of software, to take care of it and
fix its bugs. This way, we distribute the effort over a large number of
> Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10
> or more CDs. How do you explain to a user why there are 10 CDs, but this
> popular package is not included, and that package he needs is not
One of the nice things about not having customers and contracts is that we
don't need to answer these questions. If a package is missing, either there
were unavoidable problems preventing its inclusion, or no one cared enough
about it. I would very much rather have a package omitted than have to
support software that no one else cares about.
> Saying "The maintainer didn't care enough about the package you need."
> only sounds like a good reason to switch to RedHat... :-(
If Red Hat ships more of the software the user needs, maybe it is a better
choice. Choice is one of the great advantages of free software, after all.
> Currently, many new upstream versions flood into unstable every day.
> Trying to get this or that package into testing is a Sysyphos task, since
> once this or that problem with moving packages into testing is solved, the
> next one pups up. 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.
I think this is more or less what was proposed in the last release timeline,
where major changes in certain packages were frozen at various dates.
> Another problem for the release is the Debian installer. The vast
> majority of Debian installations is i386. If the new installer isn't
> ready on all architectures it might be an option to ship some
> architectures without installer in 3.1r0, and add the installer for
> these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be
> released more early, and even for the affected architectures it's
> better, since additionally to the status quo (installing and using
> Debian 3.0), they can upgrade to Debian 3.1 .
I have no particular objection to shipping with only an i386 installer at
first, but the last time I checked, debian-installer (while it seems to have
made tremendous progress of late) is not ready for release on i386 either.
>  As a sidenote:
> It would be good, if the Debian Technical Committee would be more
> active, and would make decisions in controversal cases where a
> discussion on debian-devel didn't lead to a result (e.g. the GCC
> Steering Committee is much better in this respect).
Yes, it would be nice if the technical committee were composed of active
Debian developers. Currently, only one or two of them are active.