Re: so what? Re: Debian development modem

[Richard Braakman <dark@xs4all.nl>]

Vincent Renardias wrote:
> On Mon, 8 Jun 1998, Richard Braakman wrote:
> > > Every three months (fixed date) we copy the current `unstable' into
> > > `frozen'.  At this point `stable', `frozen' and `unstable' should all
> > > stay interoperable both in source and binary form.
> > 
> > This is still a major operation at every freeze time.  I like the
> > "stable pool" approach much better.  That way we are ready to release
> > *at any time*, modulo newly discovered bugs in the stable packages
> > that have to be fixed.
> 
> I also love the idea of having a pool of packages, but it seems like it
> would need a major (and long) re-engineering of dinstall of master.

That is a matter of implementation.  If the idea is sound then we'll
get there.  At worst we will have to set up a "research archive" where
we experiment with the new approach.

> > > If it's not fine with you then let's not hold up the releases -
> > > instead, go and fix those packages.
> > 
> > It's not fine with me if hamm is released with "crafty" in main,
> > because crafty is not DFSG-free.  How do I fix that?
> 
> crafty would be removed from frozen at release time.
> 
> > It's also not fine with me if hamm is released with a non-working p2c.
> > (The package is currently orphaned).  That doesn't mean I want to fix
> > it, since I have no interest in p2c.  Unless someone cares enough to
> > maintain it, it should be dropped from the distribution.  How do I
> > "fix" that?
> 
> Same as above. The release manager should remove it just before to make
> the release.

Both of these replies seem to depend on exactly the "release-critical
bug" approach that Ian was criticizing.

They also schedule changes to happen exactly at release time, which is
IMO a bad time for them.

I chose these two examples with two points in mind, I guess I should
make them more explicitly.  
  1. A large number of the current bugs in hamm are due to neglect of
     the ftp archives (both master and nonus).  "Just fix the bugs
     if they bother you" doesn't apply there, since most of us don't
     have access.
  2. We will need a mechanism for dropping buggy packages rather
     than fixing them.

I'll go get another lollipop now.

Richard Braakman


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org