Re: release update and branching

[Kenshi Muto <kmuto@debian.org>]

Hi,

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 :-)

Thanks,
-- 
Kenshi Muto
kmuto@debian.org