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.

 - don't upload until sarge releases    Advantage: ?    Disadvantage: Prevents most testing, cannot support users. It's best way for translators Thanks,

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. Just for the record, we'll need one more round of 2.4 kernel updates after rc2 because there are several new kernel vulnerabilities which haven't been fixed yet.  Let's CC Horms to again ask what the status of this is (I'm thinking of Alan Cox's fixes plus the recent ELF problems).

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. Any chances for updates in the area of i18n? More than a month ago some languages reached a level where they could be released.  Too bad for the work of the translators if their work is outcast.  Some updates in the existing translations is probably also desired. Anton Zinoviev

Any chances for updates in the area of i18n? More than a month ago some languages reached a level where they could be released.  Too bad for the work of the translators if their work is outcast.  Some updates in the existing translations is probably also desired. Adding a language increases memory requirements and can break the installer. We've seen problems in translations break the installer too many times too. Either rc2 is ready to be used for a debian release or not; I happen to think it is.

Either rc2 is ready to be used for a debian release or not; I happen to think it is. Rc2 is not under question.  The question is whether there will be language updates in d-i before the release of sarge or not. Anton Zinoviev