release-teamKiBi’s bloghttp://mraw.org/blog/tags/release-team/KiBi’s blogikiwiki2014-08-10T19:48:22ZWhy is my package blocked?http://mraw.org/blog/2014/08/10/Why_is_my_package_blocked/2014-08-10T19:48:22Z2014-08-10T17:45:00Z
<p>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.</p>
<p>I took over d-i release maintenance in May 2012 and only a few uploads
happened before the <code>wheezy</code> freeze. I was only discovering the job at
the time, and I basically released whatever was in <code>testing</code> 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.</p>
<p>A few uploads happened after the <code>wheezy</code> release and there’s already
a <code>Jessie Alpha 1</code> release. I was about to release <code>Jessie Beta 1</code>
after some fair bits of testing, a <code>debian-installer</code> upload, and the
only remaining bits were: building installation images (hello Steve),
and of course communication (mail announce and website update).</p>
<p>Unfortunately a new upstream release reached <code>testing</code> 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
<code>testing</code> can induce.</p>
<ul>
<li><p>parted 3.2-1 was uploaded on 2014-07-30 and migrated on 2014-08-05.</p></li>
<li><p>parted 3.2-2 fixed a regression reported in Ubuntu only
(<a href="https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1352252">LP#1352252</a>)
which I also hit with images built locally after that migration.</p></li>
<li><p>I then built some images locally using fixed parted packages but
then discovered that auto-lvm was still broken, which I reported in
<a href="https://bugs.debian.org/757417">#757417</a>.</p></li>
<li><p>After some investigation Colin confirmed some behavioral changes in
this new parted release, which imply the need for an update of
several other <code>partman-*</code> components:
<a href="https://bugs.debian.org/757661">#757661</a>,
<a href="https://bugs.debian.org/757662">#757662</a>,
<a href="https://bugs.debian.org/757663">#757663</a>,
<a href="https://bugs.debian.org/757664">#757664</a>,
<a href="https://bugs.debian.org/757665">#757665</a>,
<a href="https://bugs.debian.org/757666">#757666</a>.</p></li>
<li><p>Thankfully fixes have been added for all of those, but more testing is needed
before possibly urgenting those packages so that they get into
<code>testing</code> as soon as possible.</p></li>
</ul>
<p>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.</p>
<p>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 <code>debian-release@</code> and <code>debian-boot@</code>
asking for an unblock. I’ll then review your particular package, and
either let it migrate to <code>testing</code>, or delay it until after the
release.</p>
<p><strong>Update:</strong> <a href="https://lists.debian.org/debian-devel-announce/2014/08/msg00003.html">official announcement</a>.</p>
Bus factorhttp://mraw.org/blog/2012/07/15/Bus_factor/2013-12-17T02:11:29Z2012-07-15T17:15:00Z
<p>Stuff/team I’m currently involved with:</p>
<ul>
<li><p>Debian System Administration: I’m just in the <code>porter-*</code> 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:
<a href="http://dsa.debian.org/doc/install-req/">Chroot Install Request Guidelines</a>.</p></li>
<li><p>After having maintained the <code>kfreebsd-*</code> 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 <code>debian-wb-team@</code>. It’s
been a while since it’s been split up from <code>debian-release@</code>, and
instructions are still available in
<a href="http://release.debian.org/wanna-build.txt">wanna-build.txt</a>.
Basically: anything buildd-related goes to
<code>$arch@buildd.debian.org</code> or <code>debian-wb-team@lists.debian.org</code>,
with the sole exception of binNMUs, which are handled by the
release team.</p></li>
<li><p>Speaking of which, I joined the release team a few months ago;
plenty of (not-so-)funny things to do, like coordinating
transitions to <code>testing</code>, 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 <code>wheezy-backports</code> is open).</p></li>
<li><p>Given nobody on <code>debian-boot@</code> stepped up to prepare new
<code>debian-installer</code> releases, I figured I would give a hand there
until somebody more involved with <code>d-i</code> would manage that on the
long run. That’s
<a href="https://lists.debian.org/20120610232949.GA1059@mraw.org">a</a>
<a href="https://lists.debian.org/20120624215418.GU6468@mraw.org">lot</a>
<a href="https://lists.debian.org/20120708160952.GM29142@mraw.org">of</a>
<a href="https://lists.debian.org/20120709231514.GA6071@mraw.org">heavy</a>
<a href="https://lists.debian.org/20120711200313.GC6631@mraw.org">work</a>,
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 <code>d-i beta 1</code>.</p></li>
<li><p>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 <code>pettersson</code> (the very nice machine on which images
are built), using the <code>debian-cd</code> account. The intent was to make
sure <code>debian-installer</code> could safely migrate from <code>unstable</code> to
<code>testing</code>. That has happened lately, so images are being prepared.</p></li>
<li><p>And of course I’m still maintaining the whole X stack, with the
help of a few other guys on specific areas.</p></li>
</ul>
<p>I don’t feel like
<a href="http://en.wikipedia.org/wiki/Bus_factor">getting hit by a bus</a>, but I
would hate burning out and going away from all this.</p>
<p>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 <a href="http://mraw.org/2010/01/31/Saving_private_GI/">from DirectFB to X11</a>).</p>
<p>The same holds with non-packaging teams. I’m pretty sure Steve would
love to see new members in <code>debian-cd</code>. I’m also pretty sure having
more people involved in the <code>d-i</code> 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.</p>
Busy Release Teamhttp://mraw.org/blog/2012/05/20/Busy_release_team/2013-12-17T02:11:29Z2012-05-20T14:40:00Z
<p>With the
<a href="https://lists.debian.org/debian-devel-announce/2012/05/msg00004.html">sound of the freeze approaching</a>,
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
<a href="http://release.debian.org/transitions/">tracker summary</a>:</p>
<p><a href="http://mraw.org/blog/2012/05/20/transitions-20120520.png"><img src="http://mraw.org/blog/2012/05/20/transitions-20120520.png" width="794" height="491" class="img" /></a></p>
<p>Of course there are some transitions that started because maintainers
“forgot”
<a href="https://wiki.debian.org/Teams/ReleaseTeam/Transitions">how transitions are supposed to work</a>, but we’re trying to get things done anyway.</p>