This proposal leaves me speechless. The replies even more. The sole fact that there are positive replies kills me. I m really starting to think that this Project could do a lot better without some people. Now if you ll excuse me for a sec, I have a urgent need to vomit. Reality check, people. Get back on the ground.

Just saw the LF announcement:

http://video.linuxfoundation.org/category/video-category/-linux-foundation-video-contest

I love the effort, and I'm sure people will do great work, but there's a problem here. There needs to be *two* contests. The first, with the award that they propose, should be the serious one - The one that might get rolled out to suits and businesses everywhere, that we'd be proud to show off on our corporate web sites.

Then there's the second category. The "too honest" ones that get made for the equivalent "I'm a Mac" / "I'm a PC" ads and wind up on YouTube and email attachments. Not so much fan fiction as fan honesty. =)

I'm thinking start with a focus on a keyboard, crusted with Doritos and possibly an ashtray beside it, zoom out to a couple people playing Quake or Tetrinet or something that clearly haven't washed in days, zoom out, show that this is a dorm room. The room next to it (with cutaway walls and what not) has someone composing an email saying that either Gnome or KDE sux0rs. Further out, two floors, more rooms: Some people lit just by the glow of a CRT, decorated by Debian and Gentoo logos, maybe a vague outline of some porn on a monitor. The zoom out picks up to show ESR writing another book, maybe another ELER comic being written, someone "upgrading" their home wiring, various people arguing, one shower in the building total, and finish the zoom out and fade in the facade to the building: All shiny, glass and steel with a front door with a business person leading a tour past it saying "These are the Linux Development Labs, where all the magic happens. It's closed to visitors right now (points to goth in the back with a laptop who's probably running kismet), except you - you're welcome in." And then fade in the letters "We are Linux"

The soundtrack to this should be a background hum, just at the edge of what a TV speaker will play for volume. Queue in fifths and octaves during the zoom out, fade in some drum and base, some Simcity type of background talking and open up the chord as the words fade onto the screen.

(This is fiction, people. Noone expects another ELER)

Just FYI, I've updated my Playing Starcraft on Linux using Wine article from a few days ago, adding some more info about:

• Brood War installation.
• Multiplayer LAN games, firewall settings for network gaming.
• Playing Starcraft on netbooks (which works astonishingly well), tested on my One A110 VIA VX800 netbook.

Please read the updated article for details.

A small point release to fix some small bugs before it's 2009...

• The Upload button now works
• Don't delete images if the upload fails

The tarball is here, and Debian packages are building now. NP: Live at the Royal Albert Hall, The Cinematic Orchestra

Two policy issues have been brewing in debian and I ve been mostly quiet about them because I ve been busy with TTLLP work. One is the Lenny release GR which I m still trying to make sense of. I mean: yikes! I ve been reading debian-legal and -vote for years and this ballot confuses me. I think I ll vote 5324671 but I m really not sure what that means. The other big issue is that Manoj has resigned as secretary. I think this is a good thing, if for no other reason than he s been secretary for 7 years and I feel it s not healthy for one person to hold that post too long in a thousand-strong group. I ve disagreed with Manoj about some tasks, but I didn t see any point in making this difficult job even less fun, so I stopped criticising him a while ago. Since then, my comments on the secretary s work have usually been limited to small review comments on ballots (which are then apparently ignored anyway, but at least I offer help). I m apprehensive about who will replace Manoj. In the short term, Bdale Garbee acts as secretary, but surely Bdale is busy enough already? Given his increased vote-taking activity, Neil McGovern seems a likely choice, but the work left undone after his term as SPI secretary may count against him. More generally, I think there s a problem with Debian s secretary, so anyone who would be a good secretary would probably refuse to do it as currently defined. There s an email about bundled votes and the secretary by Steve Langasek which touches on this major problem:

the secretary is the *only* line of defense against gaming of the GR process by a small group of developers who propose an uncontroversial but orthogonal amendment that will always win over the alternatives, in the process preventing the will of the project from being formally enacted

In other words, in Debian, the secretary is both secretary (usually an appointed or consensual post in most organisations, in my experience) and chairman (usually an elected post) - both doing the hard administrative leg-work and actually ruling on contentious issues, rather than just giving an opinion to the chairman. Manoj commented that he would be happy if the constitution was changed, to clarify the issue, or to explicitly add another entity to handle intepretations . Is it time to split the secretary s role?

This morning, Alan sends me the link to the subscription form. We are now ready to accept participants for OCaml Meeting 2009. Last week, I was at the annual CAML consortium meeting. We talked about OCaml Meeting with M. Leroy and other participants. Most of us, think this meeting is a real great way to make OCaml user meet. This can be the start of great projects, just because people realized that a real OCaml community exists. The INRIA seems really enthusiast about the meeting, maybe INRIA team will be directly involved in the organization in 2010. I hope 2009 meeting will be as good as the former. At least this year, we are doing things quite in advance and the whole organization will be a little bit more "professional". OCaml Meeting webpage

Taking on from Wouter's post on metablogging, I can only say that official sounding blogs are very off-putting and I stop reading them very quickly. If a blog (or more typically the blogger) starts thinking too much of their blog, considering it an enduring reference or a permanent piece of documentation then that blogger is deluded. A typical sign of such a blog is a long list of references at the end and topics that try to stipulate how other people should blog.

To me a blog is merely the opinion of the blogger. I do use my blog for announcements but only when the subject matter isn't finalised and / or isn't ready for widespread usage outside a limited list of developers. Where things are more certain, I use mailing lists and if things are just records of what happened at a particular event, I'll use the News parts of websites. As for the time taken to write a blog entry - as short as possible - like this one. Gotta go....

I think we all in Debian agree that the current discussion and the votes are a cruel mess. But if anyone wants to blame anyone else for this, please consider some facts: The outcome of the vote depends on what is to be voted on. If the vote is "Eat shit or die" a majority of people might choose the shit. That's why our constitution allows everyone to amend the vote, to offer more options, so that people can vote for what they actually want. This might get messy, especially if the process is chaotic. It can only work if people take the time and consideration to discuss the suggestions long enough to get to sane values. But if you haste it will get messy. That there is so much haste currently is also our all fault. Of course if more people had worked on the firmware issues, we would not have this problem. But this is not the fault of one side. The other side could have worked on that too. Some "But I have nothing against firmware in the kernel." is as little an excuse for not working on it as "I do not need kernels for hardware without free firmwares". Because the outcomes of the last votes for sarge and etch made clear that just having the stuff in the kernel is no solution. Everyone that did not propose a GR to allow non-free firmware more than half a year ago and did not work on easing things for users needing non-free firmware has either to admit that it is also his fault by omission as much as those not wanting the firmware in there and not having done more to get rid of it. Or you have to admit you willfully did nothing to now take the release hostage for your goals. That said, I also want to speak against the "lenny without firmware will be totally unusable". I didn't look at the details. But when I in the last half year had some servers that needed some firmware, that was not even in the kernel and on the installation media, I was extremely surprised how easy it was to put it there and how anything went correctly without thinking much, the installer just copied the needed files directly on the installed system. The initrd generator must have included that somehow (for it was a firmware for the sata card, and it actually boots). And I think it might not even be needed on the installation media, but might also be inserted by some other means. (But putting it in the initrd of the netboot installer was just so easy, that I tried nothing else). Some post-scriptum: I personally would have deemed it more clean to have Peter Palfrader's proposal not made to amendment of the other vote. But if it had been handled otherwise, I definitely would have suggested an amendment to it (and perhaps some others, too). So do not think it would have made things much faster or easier to grasp. Another post-scriptum: It's the job of our secretary to protect and interpret the consitution. The only thing looking at the current discussions is why political partisans in some western countries not yet got to the idea of recalling judges whose job it is to protect the constituion. Perhaps because in that setting it would sound just too absurd...

I went on IRC to ask a simple technical question earlier today. I wasn't going to ask it in the #debian-devel channel, since it was a samba question rather than a debian-related one; but since my IRC client was still running, and had that channel active, I couldn't help but notice some discussion about "what-ifs" when there isn't a secretary, and who gets to do what then. Surely this was idle speculation, I thought? But that can sometimes be fun, so let's look at the backlog, and see... That's when I found out that this wasn't, in fact, idle speculation. Oh dear. Well, that's the end of an era, I guess. Not that it wasn't totally unexpected; when I learned that Neil McGovern had become "assistant secretary", I already suspected that Manoj was going to resign eventually, and he does confirm that suspicion in his resignation email. However, the suddenness of it certainly was unexpected. Here's a tip of the hat for everything Manoj has done for Debian so far. I can only wish to be at your level. What does distress me, however, is a part of Manoj's email, in which he mentions some people had been trying to get him kicked from the project:

As to the people who emailed me that they are putting together a petition for the DAM to have me removed from the project, I hear you too. I am going to spend the next few days evaluating how important the project is to me, and whether I should save you the bother or an expulsion process.

Well, Manoj, if my voice means anything to you: ignore those people, and stay a happy Debian Developer. You became project secretary not too long after I became Debian Developer, and over the years I've learned to respect you as a person with great integrity for your work, who would always do what you considered to be "the right thing". Even when I disagreed with you on what "the right thing" is (and there have been cases of this happening, including this particular vote, although I wasn't very active in the discussions), I have never been able to pinpoint our disagreement on you abusing your position as secretary in order to win the argument, or some such. You have been consistent and (where necessary) predictable in performing your duties as project secretary, and that is a great compliment. I can only hope we'll see those same virtues in our next secretary. As for that expulsion process, please do not tell us who those people were, for I do not like seeing people made utter fools of in public.

This is the worst vote that has come up since I m part of Debian. And Manoj the secretary has refused to listen to the remarks of many developers about the misleading titles/summaries, about the unjustified 3:1 ratio, and worst of all, about the mixing of multiple questions in a single ballot. I have ranked misleading options ( Reaffirm social contract at least) lowest and below Further discussion and sorted all the other options according to my preference, and ranked some of them equally when the choices answer different questions (where I can not prioritize any preferred outcome). I m not yet sure if I put Further discussion first or not. There s some hope that the vote will be cancelled and redone with separate ballots but I ve lost trust in Manoj s abilities to do his job properly. I m sure he s convinced that he s doing the right thing but that doesn t help at all, on the contrary. It also means we probably should fix the constitution to make it crystal-clear how the secretary should decide whether 3:1 ratio is needed for a given resolution or not. Not really the kind of thing I enjoy within Debian, but that s the price to pay if we want to continue to work together. On this and much more I agree with Russ Alberry. Update: Manoj resigned as secretary. I want to thank him for having taken this hard decision. And I sincerely hope he doesn t resign from Debian completely as our strength is also in our diversity of opinions. Partagez cet article / Share This

Well, everybody has been very vocal about it, so I will be too: I don t like current voting ballot, I won t defend that, but I do like Manoj as Debian s secretary and I don t think he deserves all the attacks he has been subject to. Short and clear.

Have you ever gone monastic, taken a step away from the rough tumble of life to throw yourself totally and completely in one or just a few things? I have been in this state a few times before, sometimes by my own volition, other times I was forced into such state, as when I spent nearly a year homebound, sick. The last time I went monastic, I did so to finish my dissertation in 2005 and it worked rather well. In fact, I recall those few months where I barely left home (and as result my PJs) with deep fondness. I just loved the intensity and simplicity of it all, which is why I loved my other periods of self-enforced solitude/simplicity and often yearn for those moments again. The pile of writing projects I am trying to complete (or start) are mounting and honestly, I want the pile to move from a mountain to at least a hill and in order to do so, I think I will have to retreat. So tonight, I declared that upon my return from PR, I will once again go monastic but given that I have a pretty demanding full time job, I can t really go full-on monastic. I can only go semi-monastic, shirking some of my extracurricular activities and duties but I still think that I can enter into a more seclusionary (I know not really a word) mode than has been my life for the last year. I will report back in a few months with a story of success or failure about entering Monastic Mode x

I'm posting way too much to debian-vote right now, which I realize and which I'm going to try to cut back on. (I at least did start the lintian.d.o upgrade process today, so I got non-discussion Debian work done.) The reason why I keep reacting, though, is that I'm finding it frustrating that people seem to be asking the wrong question for resolving the firmware freeness argument. We currently have a strong disagreement over what the implications of the Debian Social Contract and DFSG should be for our release process. Some Debian Developers believe that releasing lenny as-is requires a special exception to the Social Contract. Some Debian Developers believe that releasing lenny as-is is consistent with the Social Contract. We've tried and failed to achieve consensus. That's the first point of my frustration: some people don't seem willing to accept that this has happened. They are apparently having a hard time understanding how anyone couldn't agree with them, and are therefore repeatedly reopening the discussion on which we don't have consensus. Once it's clear that consensus doesn't exist, this is very counter-productive. The discussion is futile, which frustrates people, and then in that frustration they become increasingly angry and harsh. Once consensus fails, all interesting decision-making processes start. A decision-making process basically reduces to "who decides?". When you have a dispute and consensus is not possible, some body has to make a decision. If people believe in the decision-making process, they can then support, or at least live with, the decision because they respect the process, even if they disagree with that particular outcome. The most important output of a decision-making process is closure: you stop debating and move on. If that doesn't happen, the decision-making process has failed, even if it makes a decision. Why does this all matter and why am I going on at such length about it? It's simply this, which I think is so important I'll highlight it:

Even people who strongly disagree on some issues can work together cordially and well in the same project provided that they can agree on a decision-making process in those areas where they disagree.

Agreeing on how decisions are made in Debian is important because that's how we continue to work together when we disagree (and we will disagree). If we can agree on how disputes are resolved, we can all respect and honor the outcome even if it isn't what we would have wanted, and then move forward. If we don't agree on how disputes are resolved, we'll keep re-arguing them rather than accepting the outcome. The discussions will get more heated, more people will get upset, and more people will not have fun working on Debian. What I've been trying to analyze on debian-vote is the "who decides" part of this question. We have a decision-making process outlined in the Debian constitution for non-technical decisions (of which this is one). That process is somewhat scattered through the document, but bringing it together in one place, it seems to go like this:

1. Developers are empowered to make decisions about their own work. That means that, according to the constitution, the primary people who get to decide how the SC and DFSG should apply are every Debian Developer in the tasks on which they're working.
2. The project leader can define an area of ongoing responsibility and delegate to a developer or a group of developers responsibility for making decisions in that area. There are two relevant delegations here. The ftp team has the delegated authority to determine what packages may enter Debian given, among other things, licensing and DFSG issues. The release team has the delegated authority to decide what goes into the next stable release and when that release happens. (Let's put aside quibbles over whether or not that authority was formally delegated; I think that we can all agree in practice that it's close enough.) The ftp team has accepted the relevant firmware packages into Debian main and hence have made a decision in their area of responsibility. The release team, through the lenny-ignore tag, has decided that the relevant packages can be part of the next release. Those are delegate decisions that have already been made, and neither of those teams seem to want to change their mind.
3. The final decision-making body in this case, therefore, is the developers at large, who can override any delegate decision via a GR. That's what Robert Millan proposed, although he doesn't seem to have realized he was doing that, and it's not marked as such on the ballot.

Now that this has happened, we all vote whether or not to override the delegate decision. The only option on the ballot that does so, by my reading, is the first one, so if the first option does not win the GR, the delegate decision is not overridden and both the ftp-master and release team decisions stand. This is why Further Discussion means we continue the release as previously planned. We have a decision-making process, which has been followed, and the current decision is to release including those packages. In order to change that decision, it has to be overridden. A result of Further Discussion on a GR means that GR does nothing, and hence the decision stands. The second point of frustration is the decision that option four on the ballot (delegate to the release team the power to make decisions about how DFSG issues affect what is included in the release) needs a 3:1 majority. They have already been delegated the authority to do that as part of their delegated authority to manage the release. The effect of option four on the project is therefore identical to Further Discussion; the only difference is whether we make a positive statement or fail to make a negative statement. It makes no sense to treat it as supersession of a foundation document when it just supports the existing decision-making process in the constitution. A third point of frustration is the apparent feeling that foundation documents like the DFSG are outside of the normal decision-making process described in the constitution. I can find no evidence of this in the constitution, but more fundamentally, the people arguing this are not stating what decision-making process they believe does apply other than "my view of the DFSG is obviously the only reasonable one and hence you should follow it." This reduces to a plea for consensus, which we've already established that we don't have, and hence, as mentioned above, is horribly unproductive to keep raising. There will never be a policy document that is so clear that everyone will agree on its implications in every situation. I find it much more useful to analyze governance processes by looking at who decides disputes rather than looking at position statements. The decision-making process is what will determine the outcome of all the really interesting cases.

I just added a script from Thomas Viehmann to our dak repository to create a few graphic files out of our dinstall cronjob. We now have (click the graph for the full size version)

• one graph that shows the whole dinstall runtime together with the two most timeconsuming parts of it ,
• one graph that shows the most interesting points of dinstall and combines the rest into an other part ,
• and one that shows the rest of them .

These images are now updated at the end of each dinstall run, showing the last 20 runs. Now, if you are an R expert and want to make the graphs look nicer, we always love to get patches. Our git repository is at https://ftp-master.debian.org/git/dak.git/ and you want to look into tools/logs.py,pretty much at the end of the file. (If you dislike git, a copy of the file is available here, and our data input file is also available. You just need to modify the header of the script, changing the path entries and can start playing. :) Yes, at the time of writing this post the two first entries look a little odd. Thats known. Ignore. Thanks.

So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others. SSD disk I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds. X server The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X. Wifi support The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717). Sound support It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn t work at all if you don t pay attention. Using the microphone works fine. For reference, if you play in the mixer, Front mic means the microphone connected on the dock while Mic means the one connected on the laptop. Each Analog loopback X option goes pairwise with the corresponding Input source X setting. In order for the recording to work, I have to set Digital Input Source to Analog Input , Digital must be activated and Input source 1 defines the default input used for the recording. Bluetooth support Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the Dell 365 Bluetooth Card so I took it but it doesn t seem to work out of the box. In fact I can t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn t gave me any good result, let me a comment if you know how to get this working. Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it s somewhat difficult to guess that it s effectively a bluetooth card. Freezes, in particular with an amd64 installation I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update we ll see, but it s my biggest complaint with this laptop so far. Links Lucas Nussbaum bought the same laptop, you might want to read his remarks as well. More details Load the full article only if you want to see the lspci and lsusb output on this laptop.


rhertzog@rivendell:~$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 RAID bus controller [0104]: Intel Corporation Mobile 82801 SATA RAID Controller [8086:282a] (rev 03)
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
02:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
02:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
0c:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
Kernel driver in use: iwlagn
Kernel modules: iwlagn
$ lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 019: ID 046d:c03d Logitech, Inc. M-BT69a Pilot Optical Mouse
Bus 004 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 004 Device 017: ID 0424:2602 Standard Microsystems Corp.
Bus 004 Device 016: ID 0424:2502 Standard Microsystems Corp.
Bus 004 Device 007: ID 045e:00dd Microsoft Corp.
Bus 004 Device 006: ID 0c45:63fe Microdia
Bus 004 Device 004: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 003: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 413c:8162 Dell Computer Corp.
Bus 001 Device 004: ID 413c:8161 Dell Computer Corp.
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a5c:5800 Broadcom Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Partagez cet article / Share This

That is the sledgehammer argument people bring up when others dare to criticize the current release process. I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we simply started the freeze with much more open RC-bugs than before (~3 times more RC-bugs than with Etch). So it was foreseeable that the freeze would take longer this time. We can t solve the problem by trying to fix bugs faster, we ve tried it several times with mediocre success. That doesn t mean we shouldn t keep up fixing bugs, but we should probably accept that a certain number of people can only fix a certain number of bugs in a given time. In our case roughly 30 RC-bugs per month. So what s the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? That pressure doesn t help anyone. I believe unstable being frozen for several months is a very important problem which can have drastic consequences regarding the number of our users, and we will not solve it by suggesting to fix our bugs faster.

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