Re: I'd like to coordinate a major update of stable
Let me be a critic. Given the vacuum of release goals, there is no
need to criticise Debian for long release cycles. On the other hand,
making changes to a stable (tested) release is another matter. What
is the plan for guaranteeing that updates to slink don't break it? I
can see this working if we open a second unstable branch, slink-prime.
In that case, let's call a duck, a duck. Is this a proposal to start
another release candidate?
On Wed, Aug 11, 1999 at 08:42:40AM -0700, Joey Hess wrote:
> Wichert, Darren Benham, Joseph Carter, Johnnie Ingham and myself were
> talking two days ago at dinner and we all agreed it would be a good thing if
> we could make a major new release of stable before potato is frozen. This
> might even be called debian 2.2 and potato would then be 2.3 or 3.0.
> The idea is to update more than just the usual security updates, but avoid
> any new code that hasn't been tested for 2 to 4 months already. So this
> release would include X 3.3.3, kernel 2.2.x (where x is probably 7 with
> security patches), security updates, possibly updated pcmcia drivers, and
> possibly more (the idea of an updated apt has been bandied about).
> This dovetails very nicely with a commitment I have at VA to produce a
> similar CD in a few weeks time, and I volenteer to coordinate and work on
> this, if Richard is willing to delegate the position of stable release
> manager to me. I'm tenatively thinking about having it all ready by the end
> of the month, then freezing it and testing it for one month, for a release
> at the end of September. This would give the whole version a lifetime of at
> least 2 months, minimum, before potato could possibly be released.
> A side item:
> We continued talking about this and had an idea about the /usr/share/doc
> transition. I realize it's a bit late for these with the issue in the
> technical committe, but this is a bit different since it's effectively a
> non-technical compromise. The idea is this: In this new update to stable,
> include updated versions of dwww, doc-base, man, and whatever's necessary to
> make documentation located in /usr/share be easily accessable. Then if
> someone wants to install a potato package and see docs, we just tell them to
> upgrade to this version of stable first.
> I think I'm one of the major instigators of the whole /usr/share/doc
> concern, and while this idea isn't perfect for me, I think it's a workable
> compromise, and I would accept it.
> see shy jo
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com