This is going to be a little bit of a rant. I was originally going to address this issue in a less confrontational tone after those issues have been fixed, but it's almost two months since intrepid has been released, and I just can't take this crap any longer.
It certainly makes sense that we want SRU bugfixes to be thoroughly vetted before they make it into the distribution. I can even understand why you would err on the side of caution in some cases, but there absolutely needs to be a way to fast-track the process for high-profile bugs. There are several bugs that fit this description (don't even get me started on #59695), but I'm going to focus on two bugs that affect users of intel's 4965 wireless chip: https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.27/+bug/276990 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286285 These bugs have several common characteristics: 1. A huge user base is affected. This has to be one of the most common wireless chipset that is built into laptop these days, and nearly everyone that owns such a laptop is affected. 2. Those bugs are extremely critical, rendering affected machines practically useless. There's some serious potential here for turning users away from ubuntu or linux in general. 3. They have trivial fixes/workarounds that have no potential to introduce regressions. 4. The fixes have been upstream for ages. 5. Both bugs have been completely mishandled from the start: After someone found out in the tracker for #276990 that the bug was fixed in a current compat-wireless snapshot, the only possible fix for this bug was to update to a development wireless snapshot. Nobody even thought about identifying and backporting the patch that was responsible for fixing the problem, check the upstream tracker or contact upstream. The "solution" was to tell people to update to a random (not particularly stable, according to the comments) compat-wireless snapshot, packaged as linux-backports-modules that by the way still doesn't contain the fix for the other bug. Users were supposed to learn of this from the release notes, but of course most people don't read them. In bug #286285, it took way too long until some contacted upstream, and upstream was able point us to the fix in less than a day. There is definitely a lesson to be learned from this, which is that if people don't know what the deal is with a bug, upstream needs to be involved. In addition, the first bug has a particularly insidious property: 6. Without kernel modesetting, it is almost impossible for users to identify why the problem occurs. They just notice a blinking Numlock LED, without even a clue that this is related to their wireless driver. In short, those bugs meet all the conditions for a swift SRU, and they got into -proposed right a way, but nothing has happened since then. This is causing a great deal of frustration and is a gigantic waste of time for everyone involved: The users whose laptops keep crashing or whose logs are being flooded. The developers who triage bugs and come across duplicates. Everyone who is subscribed to the reports and has to deal with the constant spam by clueless users who don't understand how to apply the fix. Don't get me wrong, dealing with less experienced users is actually something I enjoy, but having a relatively small number of experienced users means that we don't want to p*ss off people that can actually help fix bugs. I already had a bad experience a while ago with bug #152187 (where developers basically didn't trust me that the solution was going to be implemented upstream) and now this. It's really hard to get motivated to spend your time on problems like these if it takes forever until they make it into the distribution and you need to spend more time lobbying for the fix than it takes to solve the problem. Tom -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss