bug reporting.. bugzilla

[Sriram Ramkrishna]

It's also a good way to log all new features as well.  What we really
need is to find some volunteers (hint hint). :-)  Bug systems and what
not is not going to get very far without someone to handle the bugs.  It
doesn't have to be one person but can be a shared responsibility.

As Dave mentioned, a good FAQ and maybe an expanded tutorial on
include/exclude would help.  I see the following (suggested) categories:

Bugs, Feature Requests, FAQ questions(Rsync Hangs etc), Rules (include/exclude Qs), librsync devel Qs.

sri



On Wed, Dec 11, 2002 at 10:34:07AM -0600, Dave Dykstra wrote:
> I disagree that the number of rsync bugs is too low to bother tracking
> in a bug tracking system.  I think that a lot of things have been posted
> that are genuine bugs but have been forgotten about because none of the
> developers have had the time to track them.  If bug reports were all
> dealt with quickly I agree there'd be no need for a bug tracking system,
> but that's not the case for rsync.  I think it would be a good idea to
> have a bugzilla system set up for rsync, especially if we can get some
> volunteers to watch the system and make determinations about all the
> reports that are put in.  I think it would also help to forward all
> messages put into the system to the rsync developers' mailing list.
> Having a well-maintained FAQ would also be valuable, to keep the noise
> put into the bug tracking system down.
> 
> - Dave
> 
> 
> On Mon, Dec 09, 2002 at 03:42:03PM +1100, Martin Pool wrote:
> > On  5 Dec 2002, Sriram Ramkrishna <sramkris at ichips.intel.com> wrote:
> > > What we do in the GNOME project is to find volunteers to run triage
> > > and catalog the bugs.  If you have a "bugmaster" position who could
> > > coordinate something like this.  
> > 
> > The situation is rather different to GNOME, as jw notes: the code is
> > not growing very quickly, and there are far fewer developers available
> > to work on it.
> > 
> > > > There used to be another bug reporting system but it was being ignored
> > > > so Martin turned it off.
> > 
> > Yes, I did.  I think the system was broken by some kind of
> > infrastructure migration, and since nobody seemed to use it I put up
> > this page rather than fixing it:
> > 
> >   http://rsync.samba.org/nobugs.html
> > 
> > One problem was that it used tridge's Jitterbug system, which is a
> > nice program but a bit harder to learn than Bugzilla, or at least less
> > familiar to most people.  Also, because it runs mostly over email, it
> > quickly fills up with spam.
> > 
> > But the main thing that discouraged me from maintaining it was just
> > that most of the entries were not valid bugs.  We had large numbers of 
> > 
> >  - misunderstandings of how to use rsync (operator error)
> > 
> >  - massively incomplete reports (e.g. just "it fails", without any
> >    error message.)
> > 
> >  - architectural limitations (e.g. upfront scan)
> > 
> >  - other junk entries
> > 
> > and in addition many of them were redundantly reported.  I think
> > probably >90% of entries were like this.
> > 
> > You can see this to a lesser extent in the FAQ-O-Matic:
> > 
> >   http://rsync.samba.org/fom-serve/cache/223.html
> >   http://rsync.samba.org/fom-serve/cache/39.html
> >   http://rsync.samba.org/fom-serve/cache/233.html
> > 
> > Too many people fail to realize that filing a useful bug is actuallly
> > a lot of work and requires that the reporter actually put a bit of
> > thought into the problem. </rant>
> > 
> > So the database was full of things that were not really bugs, which
> > made it pretty useless either for people who wanted to find out about
> > a bug they might be experiencing, or developers wanting to know how
> > many bugs there are.
> > 
> > I'm sure GNOME has had this too, but if I understand correctly they
> > reduced their junk bug count in the first place by throwing out the
> > whole database, and then by putting a lot of work into triage and
> > cleaning.
> > 
> > I think a better way go forward would be for volunteers to help
> > maintain an FAQ.  This might be a good way to address common problems,
> > whether they result from misunderstandings or from program errors.  It
> > could be in FAQ-O-Matic or something else.  
> > 
> > Since new bug reports are relatively rare, but problems and
> > misunderstandings seem to occur repeatedly I think this would be the
> > most useful way to get all the information in one place.
> > 
> > So who's interested in working on that? 
> -- 
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html