Release work, Dudesconf and, oh my, with Minirok to Sevilla
These last two weeks most of my time has been sucked into getting Python 2.5 as default into testing. That’s done now. I made use of the block uploads thingie ftpmaster implemented for the release team to use. Basically, if your package could disrupt an “almost there” transition, the upload will be rejected.
The blocks were in place for 5 days, which I think it’s acceptable. As long as we don’t end blocking stuff for very long, I think we should be fine. See the end of this post for more about this.
Though it was quite a bit of work, I’m very glad I took care it myself, since now I really feel I’m 100% back to Debian, after the time I spent off for health reasons.
Update: Oh, and I forgot to say: having control over britney has really really helped. Thanks a lot Joerg for that.
Dudesconf
Tomorrow I’m leaving to Coruña for Dudesconf, which is a kind of Debconf-ES. I’m giving an introductory talk to Git, a semi-lighting talk about grep-dctrl (30 min.), and (gasp) a talk about Debian packaging with a VCS. We may have a Debian Quiz as well.
I’m so looking forward to it, since many people who’ll attend are amongst my most loved ones, and I already missed last year’s since I wasn’t fully recovered yet. See you there!
Minirok and Sevilla
One of the reasons I wasn’t fully back to release management during the past 5 months or so is because I spent as much time as I had doing development for Minirok. I don’t think I mentioned here before, but I was participating in a Free Software Contest for college students organized by the University of Sevilla, Spain. Such effort finally paid off, since Minirok was elected as one of the finalists.
This means next week I’ll go to Sevilla, to make a presentation of the project, and who knows what more. ;-)
I’m very excited.
Finally, more on blocking uploads
This Python 2.5 transition was the first time the block uploads feature was used, and there were a couple bumps along the way. In particular, a couple packages were blocked, when they shouldn’t have been (libqt4-ruby and evolution-sharp), and one needed package was not blocked, though Rene Engelhard thankfully spotted it very quickly (mono).
The problem is it’s not completely straightforward to generate a list of all the stuff that could possibly affect the transition. What I did was to make a run of britney on an arch that had all the needed bits in place, and block all the packages that migrated together as a result of the hint.
This fails in two ways:
it can include stuff that is not needed for the transition, namely unrelated packages that happen to become candidates for testing by one of the their dependencies having migrated as part of the hint. This is what happened with libqt4-ruby and evolution-sharp.
it can miss stuff that is needed, like packages that can migrate by themselves, so the main run prior to the hint migrates them, and hence do not show up as part of the hint, but that some package of the transition depend on. This is what happened with mono.
The second problem, though, can be fixed by parsing the excuses list and blocking stuff that some bits of the transition depends on. Easy enough.
Yet, there are more cases when things can go wrong, for example a shlibs-bumping upload of a package (say, sqlite3) linked against by some package still needing a couple of builds (say, qt4-x11).
For that, blocking uploads is not an option, since that’d be an insane amounts of packages that, furthermore, can be uploaded if they don’t bump shlibs, so I guess we’ll have to ask in the next release update that shlibs-bumping uploads are coordinated in -release too, at least when close to finishing a transition.