[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: so what? Re: Debian development modem

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.

> > Bugfixes must be applied to frozen, and important ones to stable too.
> > After one or two months of beta frozen should be stable enough to
> > release.
> What happens if the bugs don't get fixed?  Release buggy packages?
> Deciding not to release a package that has grave bugs is entirely
> different from threatening to burn the house down.

The current behaviour is that we are waiting for critical bugs to be
fixed for 4 or 5 months, then the packages are dropped at release time if
the bugs still aren't fixed. IanJ is suggesting to shorten this delay to 1
month. (Buggy packages should _not_ delay the release, but I still think
that packages which are too buggy and not essential should not be shipped 

> > 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.

> > We also need to make automatic building a real possibility.
> Now this I agree with.  It is already happening.  Witness netgod's
> recent efforts at getting the sparc tree up to date, he uploaded
> some 300 packages in one day.

The only thing needed to fully automate recompilation is source
dependencies, but quinn-diff+netgod's tool already automate this process
pretty well for most packages.

- Vincent RENARDIAS                 vincent@{waw.com,pipo.com,debian.org} -
- Debian/GNU Linux:           Pipo:                    WAW:               -
- http://www.fr.debian.org    http://www.pipo.com      http://www.waw.com -
- "La fonctionnalite Son Visuel vous delivre des avertissements visuels." -
-                          [Message durant l'installation de Windows95]:wq 

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

Reply to: