Re: Debian's problems
On Tue, Sep 14, 1999 at 08:23:53AM +1000, Craig Sanders wrote:
> On Mon, Sep 13, 1999 at 06:25:33PM +1000, Anthony Towns wrote:
> > [0] viz, a kind of semi-unstable that only gets packages added to it
> > if they're immediately releasable. ie, they don't break boot-floppies,
> > don't break CD-rom building, and don't have any release critical
> > bugs. See somewhere under http://www.debian.org/~ajt/ for some
> > ideas/discussion/proposal on how this might be made to work.
So "non-important" packages only - no new libc6, kernel, etc??? I must be
misunderstanding - I just can't see the point. One thing that has held up
development in the past is the delay in getting new libraries etc into
unstable.
> yes, we should have done this long ago - i thought it was a brilliant
> solution to the (ever recurring) debian release problem from the first
> time i read bdale's "package pool" proposal, and his analysis of the 3
> main types of debian users.
The package pool (where collections of related, and potentially
harmful/incompatible changes are done seperate from the tree - for instance
the recent perl upgrade could have been done there - and then once all the
perl packages had been upgraded the whole lot would be dropped into unstable
on mass) is a good idea - unstable breaks for a few days rather than a few
weeks.
I'd also like to see a sort-of half-way house between Incoming and
unstable where newly installed packages sat for a few days to weed out the
nasty bugs (and hopefully where the people are slightly more clued up so
that you only get 3 identical bug reports rather than 10).
Both the package-pool and the half-way house have an added benefit which I
think we should use and document. Install scripts sometimes have hacky
workarounds for old problems - for instance if one version of a package was
uploaded and used /etc/foo/foo rather than /etc/foo. Some of these problems
could be caught at this early stage. In short we should say "things in a
package-pool or the half-way house may require manual fixups to be applied
in certain cases".
[snip]
> btw, my preferred variant of the package-pool idea is that the release
> manager has the right to fork a snapshot at any time and call that the
> "release candidate". the RM and other release-team volunteers have
> complete control over that candidate, doing *whatever* they feel is
> necessary to turn it into a releasable product, including the right
> to make any NMUs they need if the real maintainer is unable to work
> to their schedule. i call it a "fork" because development in unstable
> continues as normal, but the release team must have complete control
> over the release candidate.
Now this sounds like a great idea - although I still think that we need a
half-way house between Incoming and unstable.
I remember a situation awhile ago at work, which I think might be worth
telling:
development on the next version of product X started. Developers did
their builds and the build-team did theirs. All the builds failed, so
the build-team stopped taking in any new code and just tried to fix the
build breakages.
A few months down the line and the build-team were still having major
problems. However the developers hadn't - they had been fixing the bugs
(and adding new code), but the build-team hadn't been using the new code.
The build-team decided to bite-the-bullet and use the latest code - a
week later the builds were working _much_ better.
The statement I'm trying to state is that whilst release candidates are
great - they encourage things to stablize, bugs to be fixed; don't be afraid
to dump them on the floor and fork another candidate from a later (and in
theory better) unstable tree. Any changes _may_ need to be ported from the
old RC to the unstable tree just before the 2nd fork.
Cheers
Adrian
email: adrian.bridgett@iname.com, http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing. PGP key available on public key servers
Debian GNU/Linux -*- because I'm allergic to Prozac -*- www.debian.org
Reply to: