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 [EMAIL PROTECTED]
