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

Re: release update and branching

This thread died out without a conclusion and now that the svn
repository is branched, it's more urgent that we find a way to test
things in it. Here's a summary of the proposals, I've added updates
from the thread:

 - 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
		and is still not fully functional per the last release-manager
		This could be risky, depending on the changes we still need
		to make in sarge
 - upload to experimental
 	Advantage: Getting fixes into sarge stays easy.
	Disadvantage: Only autobuilt on 7 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: Easier for translators.
	Disadvantage: Prevents most testing, cannot support users.

It's also a week after the rc2 release now, so we probably know about
the worst problems in the release. I know of these problems, and by the
way one thing I'm sure of is that if you have fixes for these, it's fine
to upload them to unstable already:

 - sparc32 cd initrd missing isofs module
	Fixed in unreleased linux-kernel-di-sparc 0.62.
 - ia64 2.6 USB keyboard problem
	Fixed in unreleased debian-installer 20041119
 - Multi-user workstation partitioning scheme is unusable on alpha.
	Not fixed or worked around AFAIK. A workaround would likely involve
	partman-auto (remove that scheme for alpha), while a fix might touch
	partman and/or parted.
 - LVM failure on Sparc32 (at least)
	Not fixed. Probably would need partman and/or parted changes.
 - Various kernel security holes in the 2.6 and 2.4 kernels.
	Probably needs new kernel udebs built for all arches. I don't know
	if all of the recent problems are fixed in kernel-source yet, and
	they're surely not all yet fixed in kernel-images.
 - Various broken drivers (megaraid2, aic79xx 2.6, probably some more)
 	Again new kernel udebs needed, if the kernel team finds fixes
	for these.
 - #283377, a security hole in installed system if network-console is used
   only for first stage install
   	There's a network-console patch, which needs to be tested.
 - Some problems with the CDs, I belive the amiga kernel is missing,
   there may be some other mising things.
 	May or may not be fixed in debian-cd CVS. The amiga kernel fix
	was orignally commited to an automatically generated file and
	lost. Needs followup.
 - Various missing pci ids in discover1-data
 	New updates need to go in as they're prepared and tested.

If we imagine that we were already doing post-sarge development in
unstale, and we needed to get the above fixes into sarge, it would
probably work like this:

  - linux-kernel-di-<arch>: Upload to t-p-u, does not need autobuild,
    no problem.
  - debian-installer: We'd not upload development version of this
    even if unstable were open for developmental uploads, because it's
    only uploaded before d-i releases.
  - network-console, partman-auto, partman: Arch any, so a t-p-u upload
    would be annoying.
  - parted: Still frozen no matter what we do with d-i.
  - debian-cd: irrelevant
  - discover1-data: Arch all, so t-p-u uploads would not be hard,
    unless they also required discover uploads.

If these are representative of the type of problems we'll be dealing
with until the sarge release, and if we don't keep finding lots of
release-critical non-kernel, non-security, non-discover problems, then I
think that uploading developmental udebs to unstable and still getting
RC fixes into sarge will be doable. On the other hand, if we keep on
seeing many problems in things like partman and network-console, then
getting them into t-p-u will quickly become painful. Still, I'm inclined
to go with this option since it seems much easier than getting
everything set up to let us use experimental.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: