Buxy rêve tout haut

Sam is our new DPL. The margin with the second (Steve McIntyre again!) is very slim, 8 votes. And Steve only has 25 votes more than me. That’s not much either.

What we can learn from this election:

• the principle of a DPL board makes its way, I have been ranked well above NOTA and I have been mainly advocating this proposal (and this despite some votes anti-dunc-tank that I probably suffered from)
• my selection of board members was pretty good, the 4 candidates that I selected for the board are the top-4 of the election
• Debian developers are fed up by the various problems in some core teams (overwhelmed, not recruiting new members, not communicating enough, etc.). I’ll try to help Sam fix those issues, but it’s going to be a big challenge for us.

In the end, I really hope that sam is going to find a way to cooperate closely with the various candidates that are still highly motivated to work on improving Debian. I doubt that he will choose a board structure (although I would be glad to be proven wrong!), but I really hope that he will expand the 2IC principle (or something similar).

I once told sam that he would have my full support if he got elected, and I intend to stand up to this promise. I said that because I share many of his ideas. The few fears that I have are mainly on how he is going to try to address these issues. But I have no reason to believe that he’s not going to listen to what we (and I) have to say. That’s why he got ranked just after me on my ballot.

Good luck Sam, do not disappoint us!

Stratus seeks for comments from Alioth admins.

Yes I’d like to see OpenID integration with Gforge. The upstream situation is a bit difficult, so I don’t think that you’ll have official opinion from them.

In my case, I want OpenID integration because it would be cool to offer a standard wiki and be able to define ACL on some pages which refer to the Alioth accounts that people are used to use. In the longer term, we have other web services which are going to need authentication (DWTT, new version of the PTS, …) in order to provide customized content and it would be great to rely on OpenID for that part.

I’m waiting your patches!

And next time you want an opinion from the Alioth admins, please mail us instead of hoping that we won’t miss your blog entry in planet.debian.org.

This is a never ending story for me. The first time I’ve had problems with Linux’s handling of serial UART dates back to 2005 (see my previous blog post on buffer overruns). At that time I could improve the situation by applying two patches (kernel-preempt and low latency).

One year later, I have a situation where the buffer overruns are again easily reproducible at slower baudrate (54 kbauds), arguably there’s more than a serial application running this time, and it looks like the load generated by other processes (mainly watching digital I/O) renders the system less reliable with respect to its handling of serial ports.

This time I follow the advice to try out the 2.6 kernel because many “real-time improvements” (coming from the -rt branch, check its wiki) and “embedded improvements” (coming from linux-tiny) have been merged.

So I tried the stock kernel with very bad result. Results are better than the stock 2.4 but they are worse than the patched 2.4.
So I decide to try the -rt patch on 2.6, but this patch doesn’t work on my CPU card and my bugreport didn’t lead to any fix (nobody responded even though I tried hard to include the necessary information and I was ready to do whatever I would have been asked to try).

At the same time I explain my problem on the linux-kernel mailing list.
The discussion doesn’t answer my questions but still brings two ideas to try out. In the end, with two simple tweaks to the stock 2.6 kernel (mainly configuring the UART to send the interrupt as soon as the first character arrives, instead of waiting for 8 chars to accumulate in the FIFO) I have been able to get something better than the patched 2.4. And it turns out my first choices for the 2.6 kernel configuration have not been very wise so the comparison between stock 2.4 and stock 2.6 above doesn’t mean much.

Unfortunately, even if better than the patched Linux 2.4, it still doesn’t give good results in some conditions. So my primary question remains: is there a way to patch my kernel so that it will handle the serial related tasks (servicing interrupts from the UART mainly) as its primary job ? I don’t mind if such a change impact negatively the speed of the system if I can make sure that my serial exchanges are reliable.

And by reliable I mean of course no buffer overruns, but there’s a second similar problem that has been discovered: when using software handshake, the system can send out between 10 and 25 characters after the partner has sent its XOFF. Sending up to 6 characters after the XOFF is ok, more is asking for troubles because the UART on the other side will probably encounter a buffer overrun…

If you have any idea on how to resolve my problems, by any means, let me know.

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…”.

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?

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.

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!

Given the low participation, it looks like the choice of a DPL is difficult this year. It probably means that the platform of the candidates do no suit everybody… however with DPL teams, there’s more than just the DPL and in theory each member should have their own platform. That’s not the case for me because writing a platform is a big job… which I can avoid since I’m not candidate.

However I now do feel the need to tell what I would like to propose (and do) if I’m part of a team so that you know better what to expect if you vote for a team where I’m involved. I’d just like to give a warning, those items are quick notes and are in no way full- and flesched out solutions, they will need to be discussed and refined in all cases, and somes ideas may be dropped of course.

• Discuss with the core teams, ask their opinion on the problems / critics made outside. Make propositions and implement them myself when possible in order to unblock the situation when needed. Communicate the results to the DD.
• Discuss with NM, DAM and ftpmasters how to make the NM process evolve. An example of a possible solution sketched out on the basis of recent discussions could be :
  • Require from candidates entering the NM process to setup a wiki page listing their regular contributions to Debian in the last 6 months.
  • Allow NM who have been successfully sponsored on a package to upload themselves this package (and only this one, no NMU).
  • Implement changes in the LDAP database to differentiate privileges (upload, unix account, vote, email) so that people who are not requesting upload rights can have a simplified NM process
• Ensure that the scripts to help management of keyring-maint have been written.
• Suggest to the press team to work with an associated debian-press mailing list which could review the announces before being sent and which could make proposals of announces as well.
• Make irc.d.o point to OFTC to put an end to the useless split on two networks.
• Discuss with DAM to change the expulsion process: the first step should be a mediation with the DPL (or someone delegated for that task) and not a public call for “seconds”… and if the process goes further, then the message indicating that the procedure continues will be posted by the mediator which should allows for more moderated messages.
• Try to moderate the first message of a new thread on debian-devel in order to redirect misplaced messages to the appropriate list and increase the quality of the list and get back people who unsubscribed because of the noise level.
• Try to document as much as possible from the working of core teams in some wiki pages.
• Ask everyone what decisions they would like the DPL to take (maybe use polls to evaluate suggestions).

This list is neither complete nor definitive. Not all items will be achieved but each of them is a real progress IMO and I’d like to be able to work on them.

For people who are concerned by those changes, I’m sorry if you discover my ideas by this post even before I had the opportunity to talk to you… I’m posting those ideas now because they may be considered by people who are currently voting, but it does *not* mean that I’m not interested to discuss them with you.

It’s also true that some of those ideas can be implemented without being part of the DPL team and I’ll certainly try to implement some whatever the outcome of the election, but I really believe that being part of a DPL team helps greatly because you have access to some important informations, and you can effectively discuss with core teams which are otherwise difficult to approach for non-technical discussions when you’re a random DD. And last but not least, the trust of the developers is a big motivation (at least for me) to work effectively on those problems.

See this post for my personal vote recommandation and see you in 3 days for the result of the election !

So the DPL vote just started and I crafted my ballot. So it’s my turn to give you my opinion on the various candidates. Here’s my top 3 by order of preference:

1. Jeroen van Wolffelaar
   I had the occasion to work with Jeroen due to our common involvement in Debian-QA and his work on the PTS. He’s only Debian Developer since 2004 but he’s the proof that you can get involved in core teams if you’re willing to work. His commitment to Debian is impressive. He’s also a strong proponent of the DPL team concept, and he managed to gather a well-balanced team. With some changes to the DPL team concept, this can make a big difference this year.
   Yes, I hope to be able to serve the project as a member of his team.
2. Steve McIntyre
   I worked with Steve on numerous occasions due to our common involvement in debian-cd. He’s very moderate, appreciated by many people and could be very effective in mediating internal conflicts since he’s not involved in any core team. I look forward working with him, his platform is very attractive.
3. Anthony Towns
   Anthony has been doing a great job for a long time, and I really appreciate his efforts to communicate what he does. I like his idea to bring momentum to the project… and he proposed the last general resolution to bring us to a conclusion on the GFDL problem. That’s the kind of initiative that I’m also expecting from a leader. His strong opinions do not suit everybody but at least he’s trying new ideas.

All the other candidates are well-intentionned (except one) but they do no match all my (fuzzy) criterion for a good DPL.

I have not been very much involved in this year DPL campaigning, but I’m part of two DPL teams, thus I feel the need to give my point of view on the subject.

I’m not really satisfied by how the current DPL team worked out, and being on the DPL candidate team of both Jeroen and Andreas gave me the opportunity to gather information on what really happened. Also I’ve met Bdale yesterday and he gave me his opinion as well (and I really enjoyed that dinner. Thanks bdale!).

Just for the record, I’ll try to sum up what really happened: Branden had agreed to be a participant of the DPL team concept, but wasn’t a major proponent of the idea. This, combined with his personal problems, explains why he didn’t make use of the full potential of a DPL team.

Does it invalidate the DPL team concept? No, I don’t think so because the concept will evolve this year. Let’s see how it can change.

Both DPL teams would this year receive all the mails sent to leader@debian.org. This means that the members are involved from the beginning and not only on request of the leader, which means that they can pro-actively take over if they see that the DPL doesn’t manage to follow up up to its expectations (which hopefully won’t be needed this year). Furthermore I expect that the team would be informed of what the DPL does, so that the team can give its opinion on everything done, and prevent big errors (nobody is perfect, errors do happen).

But the most important thing is that the team should not stand behind the DPL, but next to him taking initiatives, and I expect the DPL to work with the team members for the best of Debian. As such I expect the DPL to accept most of the proposals of his team if there’s a consensus on it, even if he doesn’t personnaly think that’s it’s a priority for his DPL mandate.

If I am part of an elected DPL team, I will work on that basis. I do have many ideas to try, and will make proposals. I ran once for the DPL election, and if you check my platform, you can see that I always had ideas for Debian and you can see that I worked on several of them which are nowadays very common (such as the PTS, alioth, collaborative maintenance). I won’t miss an opportunity to get the project moving forward.