SRU insanity

[Thomas Jaeger]

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