Re: random thought about bug-buddy (in the 'very long term thinking' category)

[Wayne Schuller <k_wayne linuxpower org>]

hi all,

On Tue, 2002-07-09 at 02:32, Luis Villa wrote:
> 1.2 is, AFAIK, not supported by anyone, either pragmatically or as part
> of policy.

Well 1.4 is backward compatible with it so I lump them together.
 
> > b) These bug reports reflect the userbase of Gnome. Taking an extreme
> > example: if 90% of people in July 2002 are still using gnome 1.2, then
> > obviously there is big problem, but it is not with bug-buddy. 
> 
> I'd take the position that that's irrelevant: all that matters is 
> 1) what people are hacking on and
> 2) what vendors are supporting /themselves/.

No, consider my example. Imagine if a large enough people were using
gnome 1.4 that some of them starting submitting patches or new
translations. Do we want to make them take gnome 1.4 development to a
different bugzilla or cvs server?

Practically speaking, there are the odd people still submitting little
patches for gnome 1.4 (none for 59500 though). Of course, we do hope
that they all switch to gnome 2.0 as soon as the distributions do.

Every new generation will leave behind a large group of people who are
slow to migrate. We need to have an infrastructure that can scale to
serve both.

> > c) If there is an active userbase using an old gnome desktop, new
> > bug-hunters and triagers will arise from within that community. We
> > shouldn't put obstacles in front of their gnome hacking. So if anyone is
> > triaging the current platform why can't they just ignore these old
> > reports?
> 
> I'd argue that bug-buddy stack traces of this age are all either
> duplicates or resulting from broken installations. So /if/ people are
> going to suddenly rise up and give two shits about gnome 1.2, we're
> doing them a favor too. (Rather, if people rise up and give two shits
> about gnome2.0 in three years, we're doing /those/ people a favor.)

Yes the pragmatic question is, how many of these reports really are
crap?

>From my own triaging, I would say the spew of gnome 1.x reports is not
due to old fixed bugs being re-reported but real bugs need work (mostly
59500 and libzvt related). kmarass makes a similar comment elsewhere in
this thread. While the bugs are still alive, I think we need most of the
reports.


> > d) At the end of the day, bug-buddy should be putting these old reports
> > in a place that doesn't bother the people triaging the current platform.
> > This is why we use a clever tool like bugzilla, right?
> 
> Hopefully :) Dave Fallon is working on adding a GNOME version field to
> bugzilla; with luck, this will help this task immensely. But it is still
> going to take a lot of reworking of the bugzilla infrastructure.
> 
> Also, FWIW, there is no way to make bugzilla have per-version
> maintainers, and the infrastructure for that is going to be hellishly,
> hellishly ugly. So most likely maintainers are going to continue to at
> least get email from huge #s of old, crap installations for some time,
> even if they can ignore it in queries. Maintainers, this means you
> should be on my side in this discussion ;)

Yes this is a big problem. I don't want to make life harder for
maintainers, especially as gnome 1.4 should be a very small % of gnome
users in the future.

Basically we need: 
	a) a bugzilla infrastructure where people can report/triage on
different generation platforms without bothering each other (and a
bug-buddy that does a reasonable job of sending things to the right
place). luckily we already have a good cvs structure for hacking
multiple platforms at once.

	b) to produce better software. the problem would by a large go away if
we did not have the gnome-panel and libzvt crashes in gnome 1.4. Our
processes have improved greatly and I doubt such weaknesses will not go
unnoticed in gnome 2.0 and future platforms.

I will stop complaining soon about gnome 1.4 support, I will just submit
to whatever decisions are made, even if it involves blocking old
reports.

But I just want to help the gnome project infrastructure scale properly.

Can you imagine how this multi-platform support problem will be much
much worse in 5 years? Lets not cut corners in dealing with it.

thanks,
wayne