It's tme to begin planning for the next release of d-i, we have about
two weeks to get it together. Looking at the errata for beta4, a release
that just fixes most of it and does not introduce new ones would be
good, especially because the rest of the installer is fairly complete
and solid.
Of the ideas I came up with for making releases more manageable, the
best one seems to be propagating udebs to testing individually once
they've been well tested. We could use criteria like these:
- last upload was at least 5 days ago
- built on all arches (or at least all arches we will propigate it for,
but it would be better to not get arches out of sync in testing)
- successful installation reports with on any arches the change affects
- any debs/udebs required by the change or that need an update to fix it
are in testing or can be propigated also
- the risk of making the change is less than the rewards
It would be nice to have some automated or semi-automated way to manage this,
but since we don't, these decisions will need to be made manually. (However,
the count of when the last upload was can easily be put up on a web page
somewhere, can someone put that together?) Luckily, the work can easily be
split up, anyone can write up summaries like the ones below, and more
than one person can review them and decide to let them in or not.
Some other changes that happen as a consequence of doing things this way:
- The d-i images in the debian-installer package should be built
against the udebs in sarge, not unstable, though we will want
to keep the daily builds built against sarge.
- The sarge_d-i CDs become more interesting, and we will want
to direct some users at them to flush out any bugs we introduce by
changing the stuff in testing. Same with the official images
in the Debian archive.
Starting with the errata to see some things to look at moving to testing:
* Windows OS not detected.
Fixed by os-prober in unstable.
- Last upload was 2 days ago, needs 2 days.
- Built on all arches except s390, on which it is rather irrelevent.
- No installation reports yet with os-prober 0.12 that I know of.
(We need reports for i386 and powerpc, which use it.)
- No dependency issues.
- Several other bugs are fixed too, but the current version
is not enough tested. Test it more and let it age a bit and
then put it in.
* Installs an insecure kernel.
No new udebs are needed to fix this (just debs), but we do want to
update i386 to the 2.4.26 kernel udebs.
- Last upload was 5 days ago.
- No dependency issues, but the old kernel udebs will also need
to be removed from testing.
- Plenty of successful installation reports, no new problems
known with this version.
- The main risk is actually bloating the netinst iso with
2.4.25+2.4.26 udebs. Let the 2.4.26 stuff in, but remove 2.4.25
at the same time.
* Module parameters are ignored.
Fixed by busybox 20040507-1
- Last upload was 4 days ago needs 1 day.
- Built on all arches except s390.
- No dependency issues.
- Plenty of successful installation reports on i386, possibly
not enough on other arches.
- This is a potentially big change, we need to make sure the
new busybox works on all arches before putting this in. Someone
needs to find installation reports or do installs for each arch.
* Problems with console switching with the 2.6 kernel.
Fixed by bogl-bterm-udeb 0.1.18-1
- Last upload was 8 days ago.
- Not built on alpha, mips, s390.
- No dependency issues.
- I know it's ok on i386, have not checked installation reports
for other arches, though I have heard of no problems.
- Could be propigated for only i386, which is the only arch
this bug is a problem for; is probably safe for the other
arches, but needs to be built for them first, and installation
reports found.
* Common alpha hardware unsupported.
Do we have a new kernel to fix this?
* Problem with sparc support for Creator 3D and all SBUS and UPA
framebuffer devices.
Do we have a sparc kernel to fix this? Alternatively, this is worked
around by rootskel 0.74.
- Last upload was 5 days ago.
- No dependency issues.
- Built on all arches but powerpc and s390
- The changes are all either sparc-specific or arch independant,
and we have successful installation reports for the arch indep
stuff. Need to find a sparc success report.
- Assuming it's ok on sparc, this is ready to go in once it's built
on all arches.
# Sparc CDROMs may not boot.
:-(
* Wrong kernel is installed for sparc32 systems.
Fixed in base-installer 0.080, which has actually been
copied to testing already because it fixed another bad problem
(/target/cdrom). Let's see if that propigation met the criteria:
- Last upload was 9 days ago.
- Built on all arches.
- No dependency issues.
- I don't know if we got successful installation reports on all
arches before letting this in, though i386 has since tested out
ok, and the udeb in unstable was probably tested on most arches
in the 9 days it was in unstable.
- Given the problem this fixed, it was ok to let it in. If it
had only fixed the sparc kernel problem, it should have been
better tested, or put in only for sparc.
* S390 architecture is not supported.
:-/
* Oldworld powerpc is not supported (incomplete).
Still is, afaik.
* Arabic and Hebrew display problems.
No fix yet.
* Partitioner is slow (esp on hppa).
No work has been done on speeding it up, AFAIK.
There is a hppa kernel change to make forking much faster,
I don't know the status of it.
A few other fixes I would like to get in:
partman-target 20 (fixes skoleinux bug, cleans up /cdrom mount stuff)
- Last upload was 7 days ago.
- Arch all.
- partman 0.37 needs to go in at the same time:
- Last upload was 1 day ago, needs 4 days.
- Not built on s390 (which is not keeping up).
- Needs to go in at the same time as partman-target,
but also needs libc6-udeb to reach testing:
- Uploaded 3 weeks ago.
- Built on all arches.
- No dependency issues, though adds udebs.
- If it didn't work by now, we'd know.
- Let it in.
- The changes are mainly changes to which arches it is
used on.
- Success reports for mips (! sgi), m68k (!atari) are needed,
and it needs to age some before going in.
- The changes are not very architecture independent, and we have
success reports on at least i386.
- Let it in, once partman and libc6-udeb get in.
usb-discover (adds EHCI support)
- Last upload was 9 days ago.
- Arch all.
- No dependency issues.
- Small change (add EHCI support), has been tested on arches
that use this and doesn't load anything discover would not load
later.
- Safe to let it in.
ddetect
- Last upload was 9 days ago.
- archdetect is not built on s390 otherwise all built
- No dependency issues.
- The changes are architecture independent, and have been tested
by every install in the last week, apparently ok.
- Let it in.
mdcfg, partman-md
- Last uploaded 9 days ago.
- Arch all.
- Need to go in together, otherwise no dependency issues (?)
- New packages, little chance of breaking anything. Install
reports?
- Let it in if it's reported to be working, it's too late for me
to check.
So does this make sense to anyone else, or am I still let-lagged? Can
someone research some other changed udebs and add some more reports of
this type?
--
see shy jo
Attachment:
signature.asc
Description: Digital signature