A couple of rants about Launchpad

[Christopher Chan]

>> So that is the way things currently work in Ubuntu. I was wondering 
>> about the cause for full fledged releases still loaded with rather 
>> obvious bugs.
>>     
>
> My bug triage comments have very little to do with fix rates, actually.
> It's a bit of a disingenuous leap to go from "there are these specific
> problems with bug triage in Ubuntu" to "nobody ever fixes bugs filed in
> Launchpad"! Brian Murray recently blogged
> http://qa.ubuntu.com/reports/bug-fixing/jaunty-fixes-report.html, which
> is a list of all bugs that have been closed by package uploads
> throughout the Jaunty cycle so far. Note that those are only bugs that
> were explicitly annotated in a package changelog; it does sometimes
> happen that you fix a bug just before somebody reports it and then you
> close the bug separately, and that kind of case won't show up in Brian's
> report. Nevertheless, people who say that we do not fix bugs filed in
> Launchpad are simply misrepresenting the truth, knowingly or otherwise.
>   
I am referring to rather embarrassing and obvious bugs like Network 
Manager in Gnome that required expert intervention in releases. 
Installing Ubuntu 7.04/7.10 but then having to talk my then colleague 
through the terminal on the phone to fix the problem does not leave a 
very good image of Ubuntu.

Stuff like that should have been nailed in the Release Candidates and 
never released. If Ubuntu cannot handle configuring itself properly in a 
release that seriously leaves doubts about stability or reliability of 
the packages in the repository, the kernel and the interaction between 
the various libraries and their consumers. I only decided to give Hardy 
a try because I could not get an automated handling of Nvidia binary 
drivers in Centos.

Besides bugs, there are other issues. I had eight computers I was hoping 
to use as a pilot. Well, now I am down to one machine because Debian 
Installer does not have sufficient documentation to tell me how to do 
automatically do raid and lvm besides having to familiarize myself with 
what looks like hundreds of variables. Automated tools for installation 
and package management are very important for big deployments and I am 
now seriously rethinking my adversity to Fedora since things in Ubuntu 
land seem pretty much the same. There goes my hope of putting Ubuntu on 
the desktops instead of Windows...and Promethean just released 
ActivInspire on Linux too although they have missed 64-bit packages. 
Better documentation would have helped me a long way with the roll out 
of the pilot. Hitting the lists offered me no help at all. The best 
response I got was that it was possible but I got no reply when I asked 
for documentation on how to get it done.
> As Matt Zimmerman said a while back
> (http://mdzlog.wordpress.com/2008/10/29/ubuntu-quality/):
>
>   When 8.10 is released, as with each previous release, some users will
>   be disappointed that it has a bug which affects them.  This is
>   regrettable, and I feel badly for affected users each time that I read
>   about this, but it is unlikely to ever change.  There will never be a
>   release of Ubuntu which is entirely free of bugs, and every
>   non-trivial bug is important to someone.
>
> In the real world, anybody who tells you that their product is free of
> bugs (or even free of significant bugs that you're going to care about)
> is selling something.
>   
You can at least ensure that certain basic configuration tools work 
before you put them in a release. It gives a very bad image when I have 
to walk a person through the terminal running commands to work around a 
bug in a configuration tool for a basic need.
> Now, as I noted in
> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-03-05-bug-triage-redux.html,
> there are a lot of people who are doing good bug triage in Ubuntu. Those
> people sort tirelessly through incoming bugs and flag the important ones
> in a variety of ways. My beef is not with those people; they are of
> great assistance to the Ubuntu development team. The problem I
> identified is when relatively inexperienced people come in and *try* to
> help with bug triage, but for a variety of reasons end up hindering
> rather than helping. My goal was to get our processes improved such that
> this happens much less, while still having the good bug triage that
> helps developers organise their work effectively.
>
> This will not cause Ubuntu releases to be magically bug-free. Ubuntu is
> far too large and complex a system for that to be true, and our
> user-to-developer ratio is pretty high so the sheer number of bugs
> coming in makes it extremely hard to avoid losing things in the noise.
> However, I hope it will cause developers to be able to work a bit more
> efficiently, which will make things better. Not perfect; just better.
>
>   
I have not had a chance to get to know the development environment of 
Ubuntu. It was really nice of you to tell us a bit about what is going 
on. There is another thing, though not really Ubuntu specific, that 
would be great is getting kiosktool ported over to KDE 4.2. That is the 
only Linux desktop tool that exists that can manage profiles on a per 
group basis which is essential to school environments if not business 
environments.