Published by Jon on November 22nd, 2014 in Debian | Comment now »
Keep in touch
We don’t really have a lot of spare capacity to check up on things, so if we ask for more information or send you away to do an upload, please stay in touch about it.
Do remove a moreinfo tag if you reply to a question and are now waiting for us again.
Do ping the bug if you get a green light about an upload, and have done it. (And remove moreinfo if it was set.)
Don’t be afraid of making sure we’re aware of progress.
Published by Jon on November 21st, 2014 in Debian | 2 Comments »
Boy I love rumours. Recently I’ve heard two, which I ought to put to rest now everybody’s calmed down from recent events.
kFreeBSD isn’t an official Jessie architecture because <insert systemd-related scare story>
Our sprint at ARM (who kindly hosted and caffeinated us for four days) was timed to coincide with the Cambridge Mini-DebConf 2014. The intention was that this would save on travel costs for those members of the Release Team who wanted to attend the conference, and give us a jolly good excuse to actually meet up. Winners all round.
It also had an interesting side-effect. The room we used was across the hall from the lecture theatre being used as hack space and, later, the conference venue, which meant everybody attending during those two days could see us locked away there (and yes, we were in there all day for two days solid, except for lunch times and coffee missions). More than one conference attendee remarked to me in person that it was interesting for them to see us working (although of course they couldn’t hear what we were discussing), and hadn’t appreciated before that how much time and effort goes into our meetings.
Most of our first morning was taken up with the last pieces of architecture qualification, and that was largely the yes/no decision we had to make about kFreeBSD. And you know what? I don’t recall us talking about systemd in that context at all. Don’t forget kFreeBSD already had a waiver for a reduced scope in Jessie because of the difficulty in porting systemd to it.
It’s sadly impossible to capture the long and detailed discussion we had into a couple of lines of status information in a bits mail. If bits mails were much longer, people would be put off reading them, and we really really want you to take note of what’s in there. The little space we do have needs to be factual and to the point, and not include all the background that led us to a decision.
So no, the lack of an official Jessie release of kFreeBSD has very little, if anything, to do with systemd.
Jessie will be released during (or even before) FOSDEM
Not necessarily true.
Debian releases are made when they’re ready. That sets us apart from lots of other distributions, and is a large factor in our reputation for stability. We may have a target date in mind for a freeze, because that helps both us and the rest of the project plan accordingly. But we do not have a release date in mind, and will not do so until we get much closer to being ready. (Have you squashed an RC bug today?)
I think this rumour originated from the office of the DPL, but it’s certainly become more concrete than I think Lucas intended.
However, it is true that we’ve gone into this freeze with a seriously low bug count, because of lots of other factors. So it may indeed be that we end up in good enough shape to think about releasing near (or even at) FOSDEM. But rest assured, Debian 8 “Jessie” will be released when it’s ready, and even we don’t know when that will be yet.
(Of course, if we do release before then, you could consider throwing us a party. Plenty of the Release Team, FTP masters and CD team will be at FOSDEM, release or none.)
Published by Jon on November 21st, 2014 in Debian | Comment now »
If it’s not in an unblock bug, we probably aren’t reading it
We really, really prefer unblock bugs to anything else right now (at least, for things relating to Jessie). Mails on the list get lost, and IRC is dubious. This includes for pre-approvals.
It’s perfectly fine to open an unblock bug and then find it’s not needed, or the question is really about something else. We’d rather that than your mail get lost between the floorboards. Bugs are easy to track, have metadata so we can keep the status up to date in a standard way, and are publicised in all the right places. They make a great to-do list.
By all means twiddle with the subject line, for example appending “(pre-approval)” so it’s clearer – though watch out for twiddling too much, or you’ll confuse udd.
(to continue my theme: asking you to file a bug instead costs you one round-trip; don’t forget we’re doing it at scale)
Published by Jon on November 20th, 2014 in Debian | Comment now »
Don’t assume another package’s unblock is a precedent for yours
Sometime we’ll use our judgement when granting an unblock to a less-than-straightforward package. Lots of factors go into that, including the regression risk, desirability, impact on other packages (of both acceptance and refusal) and trust.
However, a judgement call on one package doesn’t automatically mean that the same decision will be made for another. Every single unblock request we get is called on its own merits.
Do by all means ask about your package in light of another. There may be cross-over that makes your change desirable as well.
Don’t take it personally if the judgement call ends up being not what you expected.
Published by Jon on November 19th, 2014 in Debian | Comment now »
Make sure bug metadata is accurate
We use the metadata on the bugs you claim to have closed, as well as reading the bug report itself. You can help us out with severities, tags (e.g. blocks), and version information.
Don’t fall into the trap of believing that an unblock is a green light into Jessie. Britney still follows her validity rules, so if an RC bug appears to affect the unblocked version, it won’t migrate. Versions matter, not only the bug state (closed or open).
Published by Jon on November 18th, 2014 in Debian | Comment now »
Make sure everything you’ve changed is in the changelog
We do read the diffs in detail, and if there’s no explanation for something that’s changed we’ll ask. We also expect it to be in the changelog.
Do save some round-trips by making sure your changelog is in order. One round-trip about your package is an inconvenience; when it’s scaled up to the number of requests we receive, it’s a serious time-sink for us.
Published by Jon on November 17th, 2014 in Debian | Comment now »
If your request doesn’t appear on the list, probably the diff was too big
There’s a size limit for mails to email@example.com, and in general that’s how we read unblock requests. If your mail doesn’t appear on the list, but you do get a bug number back, your mail is likely too large..
In this case, that’s probably a sign that we won’t accept your request without exceptional circumstances. Making so many changes in a package is almost certainly not appropriate for this phase of the cycle.
Do use filterdiff to remove automatically-generated files from your diff before sending it, which increases the chances of acceptance.
Do follow up to the bug if it doesn’t appear on the list; send a short message explaining that happened and why your giant diff should be considered.
Don’t be surprised if thousands and thousands of lines changed are rejected.
Published by Jon on November 16th, 2014 in Debian | Comment now »
Make it easy for us to review your request
The release team gets a lot of mail at this time in the cycle. Make it easy for us by:
- including as much information as you can think of
- yes, even if you think it’s too much
- remember we have probably never seen your package before
- if you do write a lot, include a short summary at the top
- not deviating from the freeze policy without a really good reason
- explain why you deviated and why it’s really good in your request
- demonstrating that you’ve considered and checked your changes carefully
- that’s one (but not the sole) reason we ask for a source debdiff (and assume you’ve read it yourself)
Published by Jon on November 13th, 2014 in Debian | 1 Comment »
It’s finally become properly autumnal, in the real world and in Debian. One week ago, I announced (on behalf of the whole release team) that Debian 8 “Jessie” had successfully frozen on time.
At 18:00 that evening we had 310 release critical bugs – that is, the number that we must reduce to 0 before the release is ready. How does that number look now?
Well, there are now 315 bugs affecting Jessie, at various stages of progression. That sounds like it’s going in the wrong direction, but considering that over a hundred new bugs were filed just 8 hours after the freeze announcement, things are actually looking pretty good.
Out of those 315 bugs, 91 have been fixed and the packages affected have already been unblocked by the release team. The fixed packages will migrate to Jessie in the next few days, if they continue to be bug-free.
Thirty-four bugs are apparently fixed in unstable but are not cleared for migration yet. That means that the release team has not spotted the fix, or nobody has told us, or the fixed package is unsuitable for some other reason (like unrelated changes in the same upload). You can help by trying to find out which reason applies, and talking to us about it. Most likely nobody has asked us to unblock it yet.
Speaking of unblocks, we currently have twenty-four requests that need to be looked at, and a further 20 which are awaiting more information from the maintainer. We already investigated and resolved 260 requests.
Our response rate is currently pretty good, but it’s unclear whether we can sustain it indefinitely. We all have day jobs, for example. One way you could help is to review the list of unchecked unblocks and gather up missing information, or look at the ones tagged moreinfo and see whether that’s still the case (maybe the maintainer replied, but forgot to remove the tag). If you’re confident, you might even try triaging some of the obvious requests and give some feedback to the maintainer, though the final decision will be made by a release team member.
After all, the quicker this goes the sooner we can release and thaw up unstable again.
Footnote: the method used to determine RC bug counts last week and this week differ, and therefore so could the margin for error. Surprisingly enough, counting bugs is not an exact science. I’m confident these numbers are close enough for broad comparison, even if they’re out by one or two.
I’ve just spent a little time squashing several bugs on the trot, all the same: insufficient build-dependencies when built in a clean environment. Typically this means that the package was uploaded after being built on a developer’s normal machine, which already has everything required installed.
It’s long been the case that we have several ways to build packages in a clean chroot before upload, which reveals these sorts of errors and more. There’s not really any excuse for uploading packages that fail to build in this way.
Please, for the sanity of everyone working with the archive, don’t upload packages that haven’t been built in a clean environment. It’s such a waste of everybody’s time if you don’t do this most basic of checks.