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
update.
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