Did we really release 8.04?

[Bryce Harrington]

On Tue, Jul 08, 2008 at 12:25:40AM +0900, Emmet Hikory wrote:
> Scott Kitterman wrote:
>     Setting up an automatic install / upgrade / remove / purge tester
> would be good, perhaps using piuparts or similar infrastructure,
> although this requires considerable resources in terms of local
> storage and processing power.  There are likely also several other
> automatable targets in terms of package state or archive consistency
> that would benefit from additional tools to track them.
> 
> > I'm not certain, however, that we need more bugs.  We need better bugs and we
> > need more fixes.  Suggestions?

I'd like to emphasize this point.  If you're trying to make water flow
through a piping system, you might first try turning up the incoming
flow, but eventually you need to switch to bigger pipes.

Ubuntu has seen huge growth in popularity, and I believe this is the
primary source of increased bug report flow.  More early testing would
be helpful in initiating this flow earlier on in the development cycle,
but what we really need is to increase the pipe size downstream so we
get an increased flow of fixes out the end.

>     In recent times there seems to be some disconnect between the
> presence of bugs and the presence of developers working on these bugs.

>From user comments I often get the sense that if only we could get the
attention of "Those Developers" to work on bugs instead of whatever
other obscure work they're doing, these bugs wouldn't be a problem.  But
"those developers" are really us right here.  Some of us work for
Canonical, more are Ubuntu community members such as members of this
list, and the vast bulk are general community members in upstreams,
other distros, etc.

Unfortunately, there's a limited number of developers in existance.  We
can definitely improve things somewhat via better upstreaming of bugs,
however we run the risk of saturating the upstreams if we merely shifted
all of our unprocessed bug work there.

Ultimately I think the true solution is to increase the pipe flow by
increasing the number of people doing development work.  I am a strong
believer that those of us who *are* developers have a duty to find ways
to help other people become developers.  I feel the old adage applies,
"Give a man a fish, he'll eat for a day; teach a man to fish, he'll eat
for a lifetime."

So I would encourage looking at ways we can help the average bug
reporter take on more of the work of troubleshooting the bugs they
find.  After all, they by definition already have the necessary
equipment and environment for doing the testing.  The first step is to
have good, detailed documentation to make the process as 'paint by
numbers' as possible for them - I've been making attempts at doing this
via docs at http://wiki.ubuntu.com/X/, and by improving the description
section of frequently encountered bugs.  Second is to remove major
hurdles that are inhibiting them, such as to enable them to test against
recent git versions (which upstream often asks for), provide packages of
test versions, etc.

>     We should also be better about chasing bugs that are fixed.  There
> are a number of bugs marked fixed upstream, or fixed in Debian, or
> with patches.  There are plenty of others for which there are good
> fixes in Fedora, SuSE, Gentoo, etc.  At least in those cases where we
> can track that a given bug exists in Ubuntu and a fix is available, we
> ought assiduously chase these: the more quickly we can go from a fix
> being available somewhere to a fix being available in Ubuntu, the more
> likely we are to be informed of a fix being available somewhere, and
> the better chance we have of a relatively small number of bugs.

Yes.  A huge part of my week-to-week work the past few months has been
exactly this.  I've scripted a few bits and pieces of my procedure, and
I dream of a day where the bulk of the process could be automated into a
web script.  User pastes in a git ID, which churns and spits out a .deb;
user installs, tests, and says, "This fixed it"; this triggers a
workflow bug for a developer to review and ok the integration of the
fix.  In addition to saving a lot of developer time, this would
eliminate most of the cycles between user / bug triager / developer that
make bug fixes take so long to produce.

Bryce