Published by Jon on January 20th, 2015 in Debian | Comment now »
With over a hundred RC bugs still outstanding for Jessie, there’s never been a better time to host a bug-squashing party in your local area. Here’s how I do it.
- At home is fine, if you don’t mind guests. You don’t need to seek out a sponsor and borrow or hire office space. If there isn’t room for couch-surfers, the project can help towards travel and accommodation expenses. My address isn’t secret, but I still don’t announce it – it’s fine to share it only with the attendees once you know who they are.
- You need a good work area. There should be room for people to sit and work comfortably – a dining room table and chairs is ideal. It should be quiet and free from distractions. A local mirror is handy, but a good internet connection is essential.
- Hungry hackers eat lots of snacks. This past weekend saw five of us get through 15 litres of soft drinks, two loaves of bread, half a kilo of cheese, two litres of soup, 22 bags of crisps, 12 jam tarts, two pints of milk, two packs of chocolate cake bars, and a large bag of biscuits (and we went out for breakfast and supper). Make sure there is plenty available before your attendees arrive, along with a good supply of tea and coffee.
- Have a work plan. Pick a shortlist of RC bugs to suit attendees’ strengths, or work on a particular packaging group’s bugs, or have a theme, or something. Make sure there’s a common purpose and you don’t just end up being a bunch of people round a table.
- Be an exemplary host. As the host you’re allowed to squash fewer bugs and instead make sure your guests are comfortable, know where the bathroom is, aren’t going hungry, etc. It’s an acceptable trade-off. (The reverse is true: if you’re attending, be an exemplary guest – and don’t spend the party reading news sites.)
Now, go host a BSP of your own, and let’s release!
Published by Jon on January 18th, 2015 in Debian | Comment now »
We have had a rather more successful weekend then I feared, as you can see from our log on the wiki page. Steve reproduced and wrote patches for several installer/bootloader bugs, and Neil and I spent significant time in a maze of twist zope packages (we have managed to provide more diagnostics on the bug, even if we couldn’t resolve it). Ben and Adam have ploughed through a mixture of bugs and maintenance work.
I wrongly assumed we would only be able to touch a handful of bugs, since they are now mostly quite difficult, so it was rather pleasant to recap our progress this evening and see that it’s not all bad after all.
Published by Jon on January 17th, 2015 in Debian | Comment now »
Neil has abandoned his reputation as an RM machine, and instead concentrated on making the delayed queue as long as he can. I’m reliably informed that it’s now at a 3-year high. Steve is delighted that his reigning-in work is finally having an effect.
Published by Jon on January 17th, 2015 in Debian | Comment now »
Perhaps I should say evening one, since we didn’t get going until nine or so. I have mostly been processing unblocks – 13 in all. We have a delayed upload and a downgrade in the pipeline, plus a tested diff for Django. Predictably, Neil had the one and only removal request so far.
Published by Jon on November 22nd, 2014 in Debian |
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 |
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 |
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 |
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 |
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.