Alternative view: by date.
A bit of history: A while ago udeb-producing packages were getting frozen on a regular fashion, when a d-i release was about to be cut. While I wasn’t looking at the time, I can easily understand the reasons behind that: d-i is built upon many components, it takes some time to make sure it’s basically in shape for a release, and it’s very annoying when a regression sneaks in right before the installation images get built.
I took over d-i release maintenance in May 2012 and only a few uploads
happened before the
wheezy freeze. I was only discovering the job at
the time, and I basically released whatever was in
testing then. The
freeze began right after that (end of June), so I started double
checking things affecting d-i (in addition to or instead of the review
performed by other release team members), and unblocking packages when
changes seemed safe, or once they were tested.
A few uploads happened after the
wheezy release and there’s already
Jessie Alpha 1 release. I was about to release
Jessie Beta 1
after some fair bits of testing, a
debian-installer upload, and the
only remaining bits were: building installation images (hello Steve),
and of course communication (mail announce and website update).
Unfortunately a new upstream release reached
testing in the
meanwhile, breaking the installer in several ways. I’ll give details
below, of course not because I want to point finger at the maintainer,
but to illustrate the ramifications that a single package’s migrating to
testing can induce.
parted 3.2-1 was uploaded on 2014-07-30 and migrated on 2014-08-05.
parted 3.2-2 fixed a regression reported in Ubuntu only (LP#1352252) which I also hit with images built locally after that migration.
I then built some images locally using fixed parted packages but then discovered that auto-lvm was still broken, which I reported in #757417.
After some investigation Colin confirmed some behavioral changes in this new parted release, which imply the need for an update of several other
partman-*components: #757661, #757662, #757663, #757664, #757665, #757666.
Thankfully fixes have been added for all of those, but more testing is needed before possibly urgenting those packages so that they get into
testingas soon as possible.
Since I’d like to avoid such experience in the future, I’ll probably reintroduce the old method and freeze all udeb-producing packages during next d-i releases.
So you know why it might happen. Your next question might be: “What to
do when your package is getting caught in that net?”. In that case,
please get in touch with both
asking for an unblock. I’ll then review your particular package, and
either let it migrate to
testing, or delay it until after the
Update: official announcement.
Stuff/team I’m currently involved with:
Debian System Administration: I’m just in the
porter-*groups, so that I can fulfill installation requests in various chroots on Debian porterboxes; this means real DSA members can concentrate on more important things while still keeping the turnaround quick for developers who want to debug stuff on exotic architectures. Reminder for that procedure: Chroot Install Request Guidelines.
After having maintained the
kfreebsd-*buildds for a while, I’m still in the wanna-build team, meaning I can take care of give backs, one of the most common requests on
debian-wb-team@. It’s been a while since it’s been split up from
debian-release@, and instructions are still available in wanna-build.txt. Basically: anything buildd-related goes to
email@example.com, with the sole exception of binNMUs, which are handled by the release team.
Speaking of which, I joined the release team a few months ago; plenty of (not-so-)funny things to do, like coordinating transitions to
testing, and more recently, dealing with unblock requests during the freeze. While the Debian world is usually driven by the “just do” motto, there’s one area where one has to learn to say “no, sorry”. Hopefully people won’t hate us for that, and we’ll find alternative ways (like backporting specific fixes, or postponing new features until
Given nobody on
debian-boot@stepped up to prepare new
debian-installerreleases, I figured I would give a hand there until somebody more involved with
d-iwould manage that on the long run. That’s a lot of heavy work, trying to get all involved packages into shape at a given moment, and getting people to fix their stuff when anything breaks. Hopefully that’ll work out and once CD images are ready, we should be able to run some more tests on those before officially publishing
d-i beta 1.
And since the CD team is also understaffed, I joined Steve McIntyre a while ago during a point release to see how that was done, and how I could help. Things drove me to the other teams above, so I couldn’t help much so far, but at least I managed to build a few test images on
pettersson(the very nice machine on which images are built), using the
debian-cdaccount. The intent was to make sure
debian-installercould safely migrate from
testing. That has happened lately, so images are being prepared.
And of course I’m still maintaining the whole X stack, with the help of a few other guys on specific areas.
I don’t feel like getting hit by a bus, but I would hate burning out and going away from all this.
People have called repeatedly for help in core packaging team. And that has been true for the X Strike Force for a while (hint: Julien only managed to pull me into this because I ported the Graphical Installer from DirectFB to X11).
The same holds with non-packaging teams. I’m pretty sure Steve would
love to see new members in
debian-cd. I’m also pretty sure having
more people involved in the
d-i team would be very nice, especially
if one could find out how to make the whole release process less
insane than it is currently. I guess we could try out new ideas right
after the release; it feels to me that right now is just not the time
to fight the current release process.
With the sound of the freeze approaching, we have been receiving a few more transition requests lately. Thankfully, a lot of them can apparently be processed at the same time, that's why we have currently the following, crazy tracker summary:
Of course there are some transitions that started because maintainers “forgot” how transitions are supposed to work, but we’re trying to get things done anyway.