AFAIK all that's blocking the rc2 release now is FTBFS on hppa due to the new 2.6 stuff. I hope that will be cleared up RSN, but if it's not, I have a fallback plan of turning that stuff back off. (Sorry guys..) 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. 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. - 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. - don't upload until sarge releases Advantage: ? Disadvantage: Prevents most testing, cannot support users. Uploading post-sarge udebs to unstable seems like the best of these alternatives to me. Especially if we're sure that after rc2, d-i updates for sarge will be limited to security fixes, fixes for any base system breakage, and maybe discover1-data updates. We often only find out about significant problems in a release a week after it's released though, so if we go this route, I think we should hold off on uploading post-sarge udebs to unstable until at least a week after the rc2 release. -- see shy jo
Attachment:
signature.asc
Description: Digital signature