[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions for the DPL candidates

Matthew Garrett wrote:
Steve Langasek <vorlon@debian.org> wrote:
 Andreas Schuldei (DPL candidate)
 Angus Lees (DPL candidate)
 Branden Robinson (DPL candidate)
 Jonathan Walther (DPL candidate)
Little advance public warning was given about this meeting, and the
scope of the discussions that would take place was not made clear

Little advance /private/ warning was given too -- I picked up my ticket the day before I left, and only had my flight booked a week before that. Up until about a few weeks before that, the plan was no more specific than to have a meeting sometime between March and May.

The agenda item for this issue, which was mailed out on the 3rd of March, was:

how to improve the turnaround of bug fixes in testing
 - decoupling ABI changes from RC bugfixes: brainstorm

release criteria for candidate architectures
 - setting per-port release requirements (porter expectations) for etch
 - how to address per-port problems that remain for sarge

As it happened, James and I were staying at Ryan's, and after dinner on Friday night (before the meeting proper started, but after we'd met everyone), we chatted about the topic and came to the opinion that removing a bunch of architectures from being release candidates would be necessary -- for reasons I hope are adequately explained in the announcement, or that will be on -devel as people ask. As it turned out, when we got to the actual meeting the next day, this was more or less exactly what Steve was wanting to propose, and he seemed to be expecting most of the objections to come from James, Ryan and/or me. So instead of that, we then spent a fair while discussing criteria for what support architectures would/should receive.

Hopefully the above provides some useful specifics for people to talk about.

As a result, the rest of the project had little input into
the decision-making process.

That's why it's posted on the lists now -- it never too late to get input into something in Debian; even after we've committed to something, we can almost always change our minds.

Do the other candidates believe that this
was the best that could be done in the circumstances, and if not how
would they avoid similiar situations (and the ensuing fallout) arising
in future?

Really, I think this is a necessary consequence of having small meetings of the relevant people; the alternatives are to invite everyone -- which is more or less the same as just having the discussion on the lists, which has its own problems that I hope have adequately been covered elsewhere; or to have meetings that don't generate any conclusions -- which strike me as a waste of time.

I don't think that's actually such a problem; in this case there really just aren't so many alternatives, and as frustrating as that is for the people who lose out, until there are some workable alternatives, well, que sera sera. And given the plan is to give porters fairly complete control over their architecture in unstable, rather than necessarily expecting it to be synced with i386; and to provide a snapshot facility for doing releases, I think this is actually /better/ than the current situation for non-release-track architectures. Certainly I think it'll be better for the Hurd than what we currently do, provided they can get their act back into gear and meet the qualifications for being in Debian at all.

Personally, I'd much rather worry about the technical side of things and let the "But you didn't follow procedure / respect my feelings" side of thing slide; personally, I think the best way of feeling good when working on a technical project is to get the technology right.

That said, I'm not completely satisfied with the way the meeting was handled (I guess that's already obvious :); and I did encourage Steve to try to present it as a proposal for comment instead of a done deal, and to forward the mail around to you and others running for DPL -- on the basis that you're/we're hopefully the best people to provide suggestions on how to move forward on this before it goes onto the lists and there's any "fallout", and, well, that it absolutely sucks to be blindsided by things like this.

OTOH, doing RM work is pretty difficult at the best of times, and only becomes more so when it becomes necessary to start proposing major and controversial changes like this, and without the forthright support of the DPL, rapidly approaches impossible. IMO, anyway.

That said, I don't think any of the implementation has been started yet, and it certainly won't be completed 'til sarge is released; so there's plenty of time for further comments or tweaks or even reinventions.


Reply to: