Some words about dunc-tank

Madcoder decided to quote some bits of an IRC conversation held on #debian-devel-fr and (of course, given his current frustration) he munges the meaning of my quote.

I was explaining that for me dunc-tank was definitely not perfect but that it was a first step in a global direction that I’d like to explore. I explained my long term project with dunc-tank in a french blog entry and I also explained it to Bruce Byfield who interviewed me as a member of dunc-tank.

My long term project always involved that decision-making of what to fund would be shared between the donors and all Debian developers. I sincerly hope to avoid many of the current criticism with this infrastructure but I can’t be sure. In the mean time, the current experiment is not run because it’s perfect and ready for generalization but because we want to see if it’s possible to get enough funding, and if it’s actually worth to invest more time in developing something more acceptable to everybody. (And also because we would really love to have etch release in december)

This is my opinion: I’m not speaking for dunc-tank although I have the feeling that others members of the board are there for similar reasons.

Update: following sam’s bad interpretation I fixed my wording to say “…decision-making of what to fund would be shared…”.

Steering committee or board?

There’s a new idea floating around: creating a steering committee for Debian. I like the principle but I think we should aim for a broader change in the constitution.

I don’t think creating a new separate structure is a good idea, because in my opinion the DPL should be the steering committee. Of course a single individual can’t play that role. And in fact, this is true for almost any task that the DPL currently has to handle.

So we need to get rid of the DPL and to replace it with a board. And that board would be the steering committee and would also have the responsibilities that come currently with the DPL hat. Why?

First of all, the role of DPL is to provide a vision but most recent leaders have not been able to do that as they tend to get overwhelmed by simple administrative work. If you remove the hope to effectively lead Debian by giving that power to a committee, then you scare everybody that wanted to be DPL because it effectively become an administrative position with no interest.

Then, in recent years, the DPL position tended to become a multi-person thingie, first with the DPL team idea and this year with the 2IC (sort of a “DPL assistant”). So it looks like we’re ready to switch to a fully multi-personal leadership: one of an elected board.

And last point, since the DPL tends to be active only on internal organizational issues, for most persons he’s only working on “political” stuff and he’s not valued as contributor leading the distribution where it needs to be lead: to the next release.

That’s why I suggest that the board should be elected for an entire release with a maximum of 21 months. After each release we elect a new board and it should be in place for 18 months ideally.

Tying the term to a release seems like the right approach to me: at the beginning the board is effectively doing most of its work as steering committee (setting/approving release goals) and at the end, during the period where we’re freezing it has more time to concentrate on organizational issues.

The questions is now: how is that going to work with the release managers? Will that position become only an administrative work of low-level coordination without any influence on the whole distribution?

The Python transition can continue

Since the initial announce of the transition to the new Python policy, there has been some grumblings due to some unexpected last minute changes.

I spent a copious amount of time discussing with all parties involved (Matthias Klose and Josselin Mouette mainly), rewrote dh\_python 2 times to accomodate everybody’s needs (those who use the XS-Python-Version field, those who won’t) while still preserving backwards compatibility and went as far as NMUing debhelper to unblock the situation (Joey didn’t want to take an active role in the dh\_python update).

But this is now over and things have settled down. All the infrastructure is now in sid, the interfaces have been defined and won’t change anymore. It’s now really time to continue the transition. Update your python related packages by following the instructions here. Please help by providing patches and NMUing all the packages that have not yet been updated. Join #debian-python on OFTC if you have any questions.

Thanks to everyone who gave a hand to update the infrastructure required for this new policy: Matthias, Josselin, Marc Dequènes for the CDBS class, Joe Wreschnig for the update of the policy, Steve Langasek and Andreas Barth for their advice as release managers.

Improving Debian as a whole

I have to agree with Joey, I have the feeling that we’re not doing many “transversal” improvements and that we’re busy enough simply trying to keep up with new upstream version of software. That’s not completely true but I also wouldn’t want Debian to evolve in that direction.

I think that less people are interested in doing large scale changes because the coordination with 1000 maintainers and 10000 packages is simply too complicated and taking too much time. Luckily we had significant improvements recently that should ease that coordination work. I’m thinking mainly of the usertags that allow us to use the BTS as big TODO list. But usertags are obscure to many people and not well documented yet.

So there’s room for improvements: that’s why I proposed a project for Google’s Summer of code called “Distribution-wide tracker tools” (see list of accepted projects here). Check the project proposal of Arnaud Fontaine to have a more precise idea of what it could give.

I want this infrastructure because I think it may help Utnubu to effectively coordinate the integration of Ubuntu improvements and because it may help Debian be more on the leading edge (instead of trying to catchup with derivatives). And last but not least, I believe many more people (with different level of skills) will be able to effectively work on some projects once the work to do has been clearly identified and registered in such a system.

The project is about to start, so all ideas/comments are welcome of course!