Re: [buildd] Etch?
On Fri, 4 Aug 2006, Wouter Verhelst wrote:
> On Fri, Aug 04, 2006 at 06:59:44PM +1000, Finn Thain wrote:
> > [snip] As I said earlier in the thread I don't see much difference
> > between releasing and not releasing...
>
> The main difference is that we want to accomodate for people who do want
> to try or use Debian/m68k, but who do not want to have to deal with the
> ever-changing Debian Unstable, or who do not want to have to run 'while
> true;do apt-get update; apt-get upgrade; done' all the time.
>
> This would probably include machines in the debian.org domain.
>
> Additionally, there's the fact of not having to support a separate
> out-of-tree release of Etch. If we have too many bugs by the time etch
> freezes and the window for fixing bugs is over, then we would have to
> maintain separate versions of the toolchain packages outside of the
> 'normal' Debian infrastructure, which would have our bugs fixed. This
> could turn out being a rather large burden, which would not be necessary
> if we could fix all the bugs in time.
When the release criteria were adopted, was there no provision made for
those architectures that couldn't meed the new rules?
Might something be done within the debian infrastructure to assist those
architectures that are excluded from the etch release, such that they
could make a late release, without disturbing the current stable user base
and without introducing the burden of out of tree packages?
-f
>
> > but I'm only an interested observer, and I'm probably missing
> > something. Assuming no toolchain problems, I'm wondering what is real
> > the benefit to releasing Etch on time?
>
> Assuming no toolchain problems, we *will* release Etch on time. But
> there are toolchain problems, and I don't think we will be able to fix
> them in time.
>
>
Reply to: