I've gone ahead and started the beta 2 release process. CD images are in place and I will send out the release announcement once the web site has updated. (Some install media won't appear in sarge until tomorrow's dinstall.)
I have to say that this release took longer to get done than I'd hoped.
We started out strong, the compromise was unavoidable and was handled as
well as can be expected, the string freeze went well, the holiday
slowdown was worse than I expected, and then it felt to me as if things
trailed off at the end instead of us making a big push to finish the
release. I'm going to think about this and try to figure out things that
went wrong and how to avoid them, and I'd appreciate any insights anyone
might have.
Anyway with luck we now have a firm release, available in the sarge
distribution, for three architectures, which is an important step along
the way to sarge releasing with d-i.
In a sense we're not done with beta2 yet, since we have between 1 and
2.5 architectures that are still in positions to possibly be added to
the beta in a week or two. At the same time, I am eager to open unstable
back up to continued development especially with so many improvements
already waiting to go in. The conflict here is that if a package is
destablised in unstable, and then the beta2 "backport" needs to get a
minor fix to that package into sarge to make it work on a pending
architecture, I won't be able to get that fix into sarge; it will be
blocked by the changes in unstable.
So starting after tomorrow's dinstall (just in case something goes
wrong), unstable is reopened for uploads of:
I. NEW udebs (partman, etc), that are not present in sarge.
II. Any changes necessary for mips, alpha, and powerpc subarches,
targeted at beta 2.
III. udebs that are only for architectures that do not plan to
release with beta 2 (such as boot loader installers for
unreleased architectures)
IV. udebs that are only for architectures that have already
released for beta 2
But is still closed to uploads of:
X. Developmental changes of udebs that are in beta2. (busybox,
build/, base-installer, main-menu, anna, etc, etc)
Porters who want to keep working on beta2 will need to use the CD images
that don't include unstable udebs for testing, and as they fix problems,
tell me what udebs include the fix so I[1] can push them into sarge.
This may make things a little bit harder for you, which is why I've
added the extra week. We can make another announcement once more ports
are ready for beta2.
There are many things I'm looking forward to seeing in the next release
of d-i. Here is my wishlist:
- security fixed, 2.4.23 kernel (with SATA support)
This should be relatively easy to roll out, I intend to update
linux-kernel-di for i386 soon, adding the 2.4.23 kernel while
keeping 2.4.22, and transition over to it. This will go into
unstable as it meets requirements I. and III. above.
- discover 2
I guess all the hard work has been done. IIRC the plan is to
upload it with a different name, so we can test installs using
it before swtiching overything away from discover 1. If this
does not involve renaming the existing discover udeb, it will
meet requirement I., and can be uploaded to unstable soon.
- partman
Likewise, the plan here is to get it into the installer but with
a menu item that makes it non-default (like autopartkit) until
we're comfortable with it. Since it meets requirement I., it can
go in soon.
- grub
Fairly early in this cycle we need to swtich to grub as the
default boot loader on i386, so we can be confident it works
before the next release. It might be nice if a few of
grub-installer's worst bugs were fixed first though.
- XFS
Could happen a number of ways, either as an alternate boot on
the CDs, or by XFS finally being added to stock 2.4.25/6, or by
d-i getting support for 2.6. I'm sure that Steve will come up
with something.
- 2.6 kernel
For some arches at least, possibly not as the default but
available as an alternate boot on the CDs. Blocked by discover 2.
- better i18n in the second stage
We need to work out something in base-config that works as well
as d-i does for all our supported languages. Kensi has some
ideas, but they are not firm.
- improved languagechooser
Possibly with country selection split out, but we need to try
it that way and see if we like it enough to add the extra
question. Christian can upload the new countrychooser when he's
happy with it (I.), but will have to wait to change languagechooser
in unstable (X.).
- improved image names
The floppy and initrd images need to be renamed using clearer
names and a deeper tree structure used to hold them on the ftp
site. The disruption should be mild, but we will have to
coordinate with debian-cd and get docs updated too.
- udebs and debs with same namea
Some key changes in base-config are being blocked because we
cannot add debs of choose-mirror, etc to the archive. At the
same time, there is some uglyness in the initrd builds that
could be avoided if we could have a udeb named libc6. This seems
doable, but will require the assistance of the ftp-master and
has the potential to cause unanticipated problems.
- switch to subversion
It would be good to reorganise the tree, and some things are
waiting on that being done. Since this has the potential to
disrupt everything else during the transition, we'll have to be
very cautious.
- better wireless support
I think that a wireless-tools udeb just went in, but a frontend
to that is needed.
- better pcmcia support
Something that works more than 40% of the time would be good.
- a manual
Seems to be making progress, but needs to make more progress.
- a graphical boot screen
Besides looking polished, one advantage is that this can avoid
confronting non-English speakers with a page of English in
syslinux.
Technically this should be both easy and reasonably safe to do
on i386. Artistically, it's a limited medium and I'm not up to
it, and I don't know if anyone reading this is. I have been
mulling over the idea of a contest of some sort.
- three more ports
Bringing the total released architectures to 7 or 8. alpha,
hppa, mipsel, and sparc seem like contenders.
Please add to this list, though goodness knows, it's long enough
already.
--
see shy jo
[1] Or rather, the ftp-master behind the curtain.
signature.asc
Description: Digital signature
