Re: Woody retrospective and Sarge introspective
Anthony Towns wrote:
> So, I'm going to try breaking my -devel-announce habit. I wonder if this
> means nobody'll notice this mail. I guess I can hope, hey?
It's all one debian mailbox, no?
> the gradual freeze: You'll probably remember that for most of last
> year I was advocating a gradual freeze: first we'd freeze
> policy, then base, then boot-floppies, standard and
> base, and finally optional and extra, then release. This
> was a complete flop. We got away with freezing policy
> reasonably well (although even it had to be "corrected"
> with a helpful little webpage [1]). We tried freezing
> base at the end of November, but by January we still had
> a fair number of severe bugs in base (glibc alone was
> still having packaging updates in late March and April),
> and base uploads started getting automatically promoted
> to testing again, albeit with twice the delay.
>
> The only part of this that probably *was* effective
> was the "NO MAJOR CHANGES!!" policy, which has been
> more-or-less in effect since last late last August (11
> months prior to woody's release, although I guess most
> of you probably could've worked that out yourself :).
> It was *probably* more effective than we needed, in fact.
The base freeze was effective for a while, but it's just very hard to
keep that up for 11 months and still have people whose main projects
have been frozen all that time be very motivated. I know that I became
very bored and went off and wrote a extra-debian 40kloc software suite[1]
in the meantime.
I think the double delay was a good idea, and no major changes good when
enforced.
> (this isn't the case, remotely) or that I have to go through huge
> flamewars fairly regularly about release oriented matters [2]. Now,
> maybe that's just a minority thing, or maybe it's just indicative of
> the project as a whole at the moment, but it's not helpful for me to be
> feeling nervous about raising these matters, least of all when *more*
> transparency and communication is what we're aiming for.
Quality of transparency and communication have been my only complaints
with you as RM. I remember a few weeks when I just could not get your
attention about a base-config bug, could never get in touch with you on
irc and email was not answered. As long as you're aiming to improve
those, I for one cannot complain. Please ignore petty politicking.
> The easiest one of these to get and keep working is probably the
> CD images. I've already talked to at least Phil Hands about this,
> and it looks like we should be able to setup raff.debian.org to serve
> jigdo images for sarge (and some isos) updated on anything up to a
> daily basis. Getting them to be bootable obviously depends on us getting
> some installation tools that work with sarge, but hopefully that can be
> worked around in the meantime -- CDs that're only useful for upgrades
> are better than none at all.
This is a good idea.
> The official solution to this is the debian-installer project. It's a
> rewrite of the installation system from the ground up, with two important
> features. The most straight forward is that it uses debconf for its user
> interaction. The more important, as far as ongoing maintainability is
> concerned, is that whereas the woody installer is built as a single
> "chunk" (ie "boot-floppies"), debian-installer is made up from many
> "udebs" (micro-debs) which, generally, are smaller counterparts to
> real debs. For example there is a debootstrap.udeb, which provides
> the installer with the tool to actually unpack the base system. It's
> built as part of the regular debootstrap upload, and autobuilds quite
> successfully. This applies to the entire d-i installer: all the tools,
> busybox, parted, kernel-image, whatever are all built as .udebs and
> that's all there is to it.
It applies when the bits of d-i are being built from cvs and uploaded
anyway. This has not been happening very well lately, and it needs to
start happening again; all changes to d-i packages should be followed by
not just a cvs checking but a build and upload. I'm referring to the d-i
specific stuff, not the packages you list above.
> Well, actually it's not quite all, and this is the first problem with
> d-i that probably needs addressing. You can't put a udeb onto a floppy
> disk and expect it to boot. You have to run a special script that gathers
> all the udebs you want to boot with (a kernel, a UI of some sort, a tool
> to let you get any other udebs you might need and aren't including from
> the net or a CD or similar), makes a filesystem out of them, and makes
> it bootable. This is fine and necessary, the part that's a problem is
> that this script is likely to need to be run by hand (not autobuilt)
> on a machine of the target architecture, probably as root. While this
> is better than the b-f's situation, it's not particularly efficient
> or scalable. What we want is to be able to upload a new version of
> debootstrap, and then have udebs automatically built, and floppy and
> CD images automatically constructed for all architectures. Probably the
> most difficult part of this is making, say, a bootable powerpc image on
> an i386 host.
I think we could avoid the root problem with that program that generates
an ext2 image from a directory tree (forget name).
The script can autobuild tarballs that can easly be converted to images;
I've been autobuilding i386 tarballs for ages. It does need periodic
hand-holding. I'm not sure I will continue doing those autobuilds, but I
do think that daily autobuilds of the d-i system for each architecture
as it begins to support more architectures is the way to approach this.
It needs one person to manage the building for each arch, perhaps.
> The third issue, just for completeness, is that d-i still only works in
> a very limited sense. It's not ported to non-i386 architectures, and it
> isn't remotely as flexible as woody's installer from a user's POV yet.
> There's no big surprise there though, really.
But it has installed a few systems now, with lot of handolding. What
state do you want it to be in before udebs begin to be promoted to
testing like regular debs? Does it languish in unstable until it can
install all architectures, or is reasonable support of one architecture
enough?
--
see shy jo
[1] http://mooix.net/
--
To UNSUBSCRIBE, email to debian-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: