Re: so what? Re: Debian development modem
On Thu, May 28, 1998 at 12:01:04AM -0400, Buddha Buck wrote:
> > On Wed, May 27, 1998 at 08:14:56PM -0400, Raul Miller wrote:
> > > Is it as simple as cutting more releases?
> > >
> > > Let's say that every three months we split off an unstable version and
> > > froze then released what we had at that point. Do you see any problems
> > > with this?
> >
> > If only it were that simple. Personally, I think a release every 4 to
> > 5 months is about right. However, testing and actually preparing a
> > release are not fun. With a volunteer organization such as Debian,
> > there has to be a commitment, starting at the top and running all the
> > way down, to get the dirty work done, even if it means putting a
> > complete (but temporary) stop to all other development work.
>
> Before work started on Hamm, there was plans to do exactly that --
> periodic releases every 3-4 months. This was because we had such a
> problem with missing deadlines.
>
> However, do keep in mind: We have had two major flag-day releases
> recently. 1.1 was delayed for a -long- time while we worked out the
> details of the a.out->ELF transition, and 2.0 is delayed as well
> because of the libc5->libc6 transition.
>
> Both of those transitions required all the packages to be recompiled to
> new standards. To be fair, the libc6 conversion is complete, and we
> also used the time to do other major overhauls (such as how we handle
> Emacs, TeX, etc, and getting the window managers to work with the
> menuing system). These overhauls also take time.
>
> We also took the time to improve the behind-the-scenes issues, like
> revamping the source packaging system, and overhauling the packaging
> system. We have greatly improved the ease of maintaining the
> distribution as well, with more mirrors, new hardware for master, and
> better helper scripts for building, checking, uploading, and processing
> packages.
>
> Also, 1.3 was a very successful release, and caused a -tremendous-
> amount of growth in Debian as well. My available list shows nearly
> 2000 packages (double that of 1.3), and we are forced to go to three
> CD's. Since the libc6 transition, as well as everything else we tried
> to do for 2.0, took so long, this growth is being absorbed into 2.0.
> This added complexity is making the release take even longer.
>
> But it is almost done. 2.0 is in a deep freeze right now, there is
> only about 100 release-critical bugs left, and some of those will be
> fixed by pulling the packages (not to pick on anything specific here,
> but is there any reason to have a non-free, libc5 "swish" (with a
> 16-month release-critical bug) and a free, libc6 "swish-e"?). We
> should be releasing 2.0 very soon. The only major stumbling block will
> be figuring out how to split it across several CD's.
>
> 2.0 is a -big- improvement over 1.3. But it also did most of the big
> changes. I expect 2.1 to be a -much- simpler, faster, undertaking than
> 2.0.
On the libc6 transition issue. Following Brian schedule, every library
should have been recompiled with libc6 on July/August 1997. Guess?
Only a few were! Three months later there were important packages that
still were libc5-based. That's part of the "dirty work" that has to be
done, and it seems not every contributor has enough time to do (Real Life
tends to require 36-hour days).
Of course we've done improvements, but we tend to concentrate in some
parts and leave the rest behind. Thus the distribution doesn't evolutes
as a whole, and problems accumulate until the release date is near.
Take a look at hamm as it was last January. Look at it now. What big
improvements have been made in those four months? And in the last two
months? As have been said already, we make a very good pre-release
distribution, but then spend a huge amount of time fixing those problems
that we haven't pay a lot of attention at.
To make it worse, when release date is near some good development
projects are stopped or delayed until the release is made, (dpkg,
boot-floppies next generation, FHS compliance ...). If we spend a few
months in "near-release-state", those projects lose momentum, and Debian
lose technological lead. And that hurts everyone, user or developer!
With more coordination, a clear schedule, and easy (and more frequent)
maintainer collaboration/replacement to fix those packages that didn't
follow the schedule we would do it better.
If that means we have to break main in "core" and "non-core" and develop
different rules (different schedules, different testing procedures) for
each set, to ease management, let's do it.
--
Enrique Zanardi ezanardi@ull.es
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: