Re: release update and branching
At 18 Nov 04 06:44:43 GMT,
Joey Hess wrote:
> So it looks very much like the release will be this weekend. I've just
> committed a release-annoucement.txt to the usual place in the tree, and
> it could do with some fleshing out. I think that's all, other than
> updating the web site and getting full CDs built.
Good work and thank you, Joey and everyone. :-)
> So on to post release and branching. It's easy to branch svn, we'll just
> copy the current trunk to a sarge branch, and begin committing
> post-sarge changes to trunk. It's harder to handle the branching in the
> debian archive, and I've considered several ways to do it, all of which
> have their problems:
> - upload to unstable
> Advantage: Easy, sid_d-i images will use them, fully autobuilt.
> Disadvantage: Any sarge fixes would have to go through t-p-u,
> which does not currently have a full set of autobuilders.
It sounds best if t-p-u will be ready near soon.
I wonder t-p-u (and t-s also?) isn't still ready.
Who's responsible people? Is really he/she working? Why won't he/she ask
help to other people at open ML? What's the real problem? Have We just
been waiting and wasting many days?
I can set up several architecture machines for release Sarge, but I heard
Debian doesn't need more machines.
> - upload to experimental
> Advantage: Getting fixes into sarge stays easy.
> Disadvantage: Only autobuilt on a few arches, we'd have to add
> experimental_d-i CDs, and do something to make the
> daily builds use experimental udebs.
It is 'better' if t-p-u won't start near soon (sigh).
Which architecuture do you need? Who has responsibility of experimental buildd?
> - don't upload until sarge releases
> Advantage: ?
> Disadvantage: Prevents most testing, cannot support users.
It's best way for translators :-)