membership status results

So, in the Membership Status GR, we sent a clear message that we wanted those decisions to be postponed. Now, we have a responsibility to prove that we were not just rejecting any change, but that our vote was really a vote against the way those decisions were announced, and/or those particular decisions. I’m convinced that our management of membership needs to be improved.

I hope that in the next weeks/months, we will be able to discuss proposals about membership status. There’s Joerg’s, there’s Lars’, there’s Raphael’s, and there might be other ideas. Ideally, each of them would be discussed and improved separately (because we can’t be expected to agree on one proposal right from the start), and finally we would get to vote on a coherent set of proposals (with an unbiaised ballot ;) to choose in which direction we want to change our management of membership. It would be great to use the DEP process or something similar for that.

It is also interesting to compare this whole story with our current issue: a secretary that ignored valid criticism about a ballot and went on with asking to vote on it. In both cases, someone that is generally trusted and respected by the project made a mistake, and failed to acknowledge it, requiring strong actions from other DDs. I wonder how the secretary crisis will end…

Debian on a Dell E4300

I received a new laptop, a Dell Latitude E4300. I was a bit anxious with its level of support on Linux, because it only recently started being shipping, and it’s full of recent Intel hardware. Also, with lenny being frozen for 5 months, we are currently a bit behind regarding hardware support.

I installed lenny on it, as I usually run testing+APT pinning. What I’m describing here is what is unsupported in lenny out of the box.

Needs a 2.6.27 kernel (iwlagn driver), Lenny only has 2.6.26. Downloaded from the kernel team’s unofficial repo. Firmware isn’t packaged in Debian (firmware-iwlwifi needs an update). Needed to download it from Intel.

Intel device, unsupported with lenny’s driver (but vesa works surprisingly well, oI only noticed that I was using vesa when I tried to play a video and found out I had no xv support).
Works with experimental’s Xorg and the experimental intel driver, but that Xorg needs some polishing. The evdev driver now handles all inputs, so the keymap has to be configured differently (as usual, #debian-x people were very helpful).

Works out of the box using pm-utils. No need for quirks.

All in all, it was easier than I expected, and support will probably be perfect for lenny+1/2 ;)

The Project membership procedures GR

So, the call for vote on the “Project membership procedures” GR was sent. Since I took part in the discussions that lead to that GR, I feel obliged to explain my point of view.

What this GR isn’t about
This GR isn’t about the merits of Joerg Jaspert’s proposal. I personally don’t think that the changes he wants to implement are what we need in Debian, but even if I fully agreed with those changes, I would still disagree with the process that led to those changes. Also, this GR isn’t about Joerg Jaspert himself. I deeply respect him and his awesome work for Debian. And I’m sure that this vote could have been triggered by decisions announced by someone else.

What this GR is about
I think that the question we are asked to vote on is:

Some people in Debian have a special role, and special privileges. Does it allow them to change important aspects of our project, without the approval of all the other developers?

Or, put differently:

Where is our limit between Doocracy and Democracy?

I’m all for listening to developers who contribute(d) a lot. I think that most people, when skimming through posts in a big thread on -devel@, will look for posts from people who did a lot of work for Debian, or who usually post interesting ideas. However, that doesn’t mean that those people should feel empowered to decide changes to important parts of our project, without first discussing those changes with all other developers, and making sure that those changes are consensual.

So, I hope that we will send a clear message that says: you are very welcome to propose changes, but please make sure that they are properly discussed within the developers before they are implemented.

Joerg’s initial mail on d-d-a, with a few s/decision/proposal/, and a final question phrased like “Any comments? Suggestions? Other ideas?”, could have been the start of an interesting discussion about how we can integrate non-developing contributors in Debian. And if too many developers disagreed, we could have had an opinion poll (it would be great to have an infrastructure for running polls inside Debian, like what Jeroen did three times a long time ago), or even a GR, like we did for Debian Maintainers.

For this actual vote, there are two similar options on the ballot (choices 1 and 2, respectively “amendment text A” and the original text on the vote page). I proposed this amendement (choice 1) because the original text is unclear, and mixes several different questions, forcing voters to answer several (secondary) questions at once, like:

  • Do we recognize that there are contributors that can’t become members of the project currently, and that should?
  • Do we want to thank DAM for bringing this up? (implicit question or not: … now that we are trying to release?)
  • Do we want DAM to work on a new proposal?

The amendment aims at going straight to the point. And yes, it is only asking the DAMs, but if the developers ask the DAMs not to do something, and the DAMs do it anyway, we clearly have a bigger problem. I believe that the way those decisions were announced was a mistake (that unfortunately none of the people involved have been willing to admit), not that the DAMs are trying to take-over Debian, so there’s no need for a stronger wording.