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

[Sander Vesik <Sander Vesik Sun COM>]

On 9 Jul 2002, Luis Villa wrote:

> > 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?
> 
> No, no, no. I never said 'translators and 1.4 hackers shouldn't use
> bugzilla.' I said, very specifically,  'very old bug-buddies should not
> function.' The leap between the two of those is /vast/.
> 

I think there is a leap hapenning in the reasoning here - just because the
bug-buddy is new does not necessarily mean that the applicationthat
crashed is new. I suspect a users first reaction to being told by
bug-buddy that it is too old is not to upgrade the desktop but upgrade
just bug-buddy. So you get the same old crash dumps, except filed by a new
and shining bug-buddy...

> What I want is for mindless users to not get a popup saying 'submit a
> bug.' If they want to fix it, force them to get out gdb and learn to use
> it- don't clutter things up with hundreds of useless reports of things
> either fixed for months or already very known.
> 
> > 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.
> 
> Yes. Preventing the submission of very, very old and very useless
> bug-buddy reports has very, very little to do with that.
> 

I don't think making bug-buddy have a time out will help with this. Or is
there a particular reason you want to see bugs for gmc (unaffected by
installing gnome2) reported by the gnome2 bug-buddy and not teh gnome 1.4
one?

[snip]

> I don't want to block all old reports. Just very old bug-buddies.
> 

Why? 

> 
> Luis
> 

	Sander

	This is the place where all
	the junkies go	
	where time gets fast
	but everything gets slow