Buxy rêve tout haut

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.

I just saw the vote of NOKUBI Takatsugu who posted it by error on debian-vote.

The vote ranked “Further discussion” second just after his preferred option. I find such a vote too *strong*. This vote really means “My option or none”, or in other words: I don’t want any compromise (which is quite strange given that his first option is the “compromise” option).

I believe that we should vote with the aim to have a winner in the end and as such we should avoid putting something below “Further discussion”. IMO the only valid reason to put something below is if that option would hurt Debian in one’s own opinion.

Just rank the options in your order of preference. I ranked “Further Discussion” last, it’s my way of accepting the diverging opinions within our project.

(So there’s nothing personal against Takatsugu, I just took the opportunity of his little mistake to point out something I find important)

BTW, if you haven’t voted, please do. Even if you don’t care about the outcome, vote and leave all the fields empty (or rank them equally), that way you’ll express that you’re happy whatever the outcome is and you won’t be part of a silent majority. And the outcome of the vote will be stronger.

This leads me to the following question: I wonder if we shouldn’t require DD to vote and if they don’t participate in 2 or 3 consecutive votes, they shall be considered by the MIA team… it would be a kind of implicit “ping of maintainers”.

Update: FYI, Takatsugu thanked me by private mail for the explanation and will recast another vote.

I want to respond to jb’s cry, after all I’m his favorite teletubby and his message is full of references to events where I’m involved. I’m sure he’s honest in his message but still he misses some points.

Julien says :

we never agreed to be nice to each other

That’s true I’m part of several other associations and I never had to sign a paper saying that I’ll be nice with others. Nevertheless, each time that someone misbehaved he was sanctionned. And nobody in the club took the defense of the faulty person in the name of “free speech”. Understand me, if we didn’t have any problem, I wouldn’t make efforts to define a “Code of conduct”.

I’m not a fan of “Ubuntu’s love here, love there” and I certainly don’t want a world of friendly clones within Debian. I believe there’s room for a code of conduct that would let us work together in a friendly manner.

this project used to be open-minded

Being open-minded applies to people not to a project. Now it’s time that you discover that with 1000 people you have far more chance than with 200 to have several narrow-minded people in the set … and that everyone has his own definition of what open-minded means.

That’s why we need to write down what’s acceptable and what’s not. I’ve heard you several times complain about the behaviour of other Debian developers, why not use the opportunity offered by a code of conduct to define how we should aim to work together ?

We are doing it all for fun

True again ! So how difficult is it to imagine that being insulted is *not* fun ? And since we’re all volunteers, there’s no good reason to let some people kill the fun out of it…

I don’t use kill-files

That’s because you have the luck to have a thick skin. I avoid kill files as well. But look at Lars Wirzenius, look at Theodore Y. Ts’o, they all recognize that they can’t stand the level of unfriendliness that we sometimes reach. I want to be able to work with everyone and not only with those who have leather instead of skin.

Help tell those people to FOAD

Is that your way of being open minded ? Ok, it’s a bit out of context but nevertheless, there’s some truth in my criticism:

• Stop yelling each time that someone mentions Ubuntu, Debian is not Ubuntu but we have so many things in common that we can both take advantages of what the other is doing.
• Even if you have a thick skin, it’s not a reason to be harsh with any other Debian developer, not everybody is like you !

And to finish this (long) post, let’s agree on something: yes we’re a technical community, yes we should put Debian’s interests first !

(By the way, on this subject it looks like I agree with MJ Ray. It doesn’t happen very often! ;-))

I didn’t attend Debconf since Debconf 1 (in Bordeaux), but this year I’ll come. I just booked the flights. I’ll be there from the 14th to the 22th of May.

See you in Oaxtepec !

During this week-end I tried to give initial impulses on several projects of interest for me :

DebianEduFrench: a new mailing list has just been setup for this project. We intend to foster cooperation between several French educational Debian-based projects. We’ll try to integrate their work into Debian directly to avoid needless duplication of effort. This follows my last call for help on debian-devel-announce. If you speak French and have good packaging skills, you’re welcome to join and help us on the mailing list.

Collaborative maintenance infrastructure: this one started as a project to handle orphaned packages but after the talk we gave at the Debian-QA meeting in Darmstadt, we agreed that it is of broader interest: in particular for mentoring future Debian developers. This tool could also interest Ubuntu which has in fact already started something covering a part of this proposal: REVU (development web site). So I crosspossted a call in several Debian & Ubuntu lists in order to create a little team to work on this project and make it happen. But there’s still room for discussions as nothing is in stone yet …

That’s enough for one week-end !

Working with serial lines can sometimes give you big headaches. I have an embedded PC based on 386 SX 40 processor. This PC doesn’t make much but it has programs using the serial line intensively. Things didn’t work as well as expected so I looked carefully what was going on … the beast was loosing bytes ! My information has been promptly confirmed by the /proc/tty/driver/serial entry. If you have “oe: X” (where X is a positive number) there, it means that one of your UART detected overrun errors.

So what’s an overrun ? An overrun happens when the UART receives data while its FIFO buffer is full. Why is the FIFO full ? Because Linux didn’t treat the serial interruption quickly enough. Why is Linux so slow ? Linux is not a real time OS and it doesn’t guarantee any response time to interruption, so Linux is not so slow but my PC really is … what happens is that interruption related to the network are treated before serial interruptions. Furthermore IDE disk interruptions can take too long too. Worst case is of course, you’re treating a disk interruption, then you have to treat the network interruption and only after that you can treat the serial interruption which in fact happened right after the beginning of the disk interruption

So fixing serial overrun is a rather complex problem since it’s really a kernel related problem. Googling on the subject I have found several ideas to explore :

• configure IDE disk to use DMA hdparm -d 1 /dev/hda, use of DMA will shorten the time where IRQ will be masked to the kernel (in my case it doesn’t work since I’m using DiskOnModule which do not support DMA)
• make disk IRQ interruptible with hdparm -u 1 /dev/hda
• use irqtune to re-prioritize the IRQ on the interruption controller. This software is no more maintained and it doesn’t work out of the box on kernel 2.4.x.

Using hdparm -u wasn’t enough to solve my problem… so I continued to look for a solution and I found one ! I recompiled my kernel with the low latency patch and the preemptible kernel patch. Those are usually used for multimedia applications where you need good responsiveness in order to deliver content in real-time but the fact is that they do work for my purpose too !

My serial overruns are completely gone at 9600 bauds. However I can still have some when running at 115200 bauds. Moreover I can create serial overrun by running a find / -type f | grep -v /proc/ | xargs md5sum in the background… I can’t make miracles with this slow processor… if you have more ideas to further improve the situation, I’m willing to try !

Congrats Anthony for trying out #debian-tech !

At least you’re not only speaking, but you’re actually making things happen. And you’re consistent in what you’re doing. That’s something we have in common, we have both worked on several projects that we formulated on platforms for the DPL election.

None of us got elected, but at least we contributed useful things back because we promised to work on it.

I wish we had more people like you in the project.

I gave this morning a quick conference presenting how the PTS works internally. My hope is to attract some contributors like aj (Anthony Towns) managed to do with the BTS. He got impressive results in a few months, I hope I’ll get some too.

Anyway, for those of you who aren’t there in Darmstaadt at the Debian-QA conference, you can still check my slides. Of course, feel free to ask me some questions if you’re currently trying to hack on the PTS… I’d love to help you if you’re gonna help me maintain it in the long run.

We got some interesting ideas for improvements, I hope they’ll evolve in some patches.

Since people complained about lack of documentation concerning Alioth I decided to write down the most important things in the Debian Wiki.

Check http://wiki.debian.org/Alioth. Feel free to complete the page and to spread the infos whereever needed.

Last week I had an interesting discussion with Benjamin Bayart about unmaintained packages which have very few users. Once the initial maintainer disappear, we usually don’t find another one having both Debian skills and a good knowledge of the package. So the software just stay there until it becomes so outdated that it doesn’t work anymore… and then it gets removed blindly. Most of those packages have a low “popcon” rating so they get removed without care.

Read the whole problematic described by Benjamin, and then see my initial mail with a suggestion on how to do better in that area.

The discussion has seen interesting developments even if there’s no consensus (yet). But it’s an important topic concerning QA, so I hope that something useful will come out of it… I’d like to have more time to implement something but I’m already overloaded… I really should have proposed projects for Google’s summer of code.