[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

release update and branching

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

Reply to: