Re: Let 'svn info' support URL argument

[Ben Reser <be...@reser.org>]

On Sat, Sep 25, 2004 at 08:42:39AM -0500, Archie Cobbs wrote:
> FWIW..
> 
> This handling of the bug database seems a little bit, er, "different"
> to me, based on past experience with other open source projects. In my
> opinion a bug database and a to-do list are different things: "bugs" are
> very raw things created and defined by users, not developers; developers
> then get to evaluate and process them. A "to-do" list is a much more
> refined and highly processed thing developers use to direct their work.
> 
> Right now it seems like you have the worst of both worlds: you seriously
> impede the flow of raw bugs from users, yet you also allow random people
> to add bugs to the bug database from the web site, thus polluting your
> "to-do" list and causing all sorts of yelling about bold red text.

That's why we call it an issue tracker, not a bug database.   I think
your biggest mistake is of thinking of it as a bug database.  It's not.
It is a database of issues we are aware of and have an interest in doing
something about.  Some of them may be enhancements (as yours was), some
of them may be real bugs, some may just be notes for us to clean some
API issue up at the next major release.

> If it were my decision I'd suggest either:
> 
>   (a) closing the bug database to random people, forcing all bug reports
>       to go through the mailing list and having a real developer actually
>       file the bug; or

I think the reason we don't do that is because we want to allow people
to file issues for us after they've discussed it.  I.E. user shows up
and says "Gosh I really wish you could get the current version of the
repo with svn info."  We say "That's a good idea, please file an issue
on it."

As you point out users are the best at defining their "bugs" (or issues
as the case may be).  Thus we want them to be able to describe it as
opposed to us.  

>   (b) freeing up the bug database (allowing and encouraging "raw" bug
>       reports), and using the bug status to indicate whether the
>       bug is really on the "to-do" list (e.g., NEW is not, ASSIGNED is).
>       By default, newly filed bugs would not be of course.

Having worked in projects that used this process I have to say it's
worthless.  The number of bugs open in the database gets to the point
that nobody pays any attention to it anymore.  Someone ends up having
pratically a full time job trying to clean the database of users errors,
duplicate reports, problems that can't be duplicated by anyone, etc...

By asking users to send us an email to the list we have a much better
chance of:

1) Avoiding duplicate reports.

2) Avoiding user errors.

3) Actually helping the person as opposed to simply having their problem
go into a black hole.

4) Actually have the communication necessary to figure out how to
duplicate the problem.

> On the other hand, just because a bug gets filed doesn't mean it
> has to be dealt with immediately. E.g.  FreeBSD works this way,
> there are thousands of outstanding bugs, but they all eventually
> get dealt with in one way or another, sometimes several years later.
> In the mean time you might say the bug is "ignored bug not forgotten".
> There is nothing inherently wrong with having lots of un-tended-to bugs.
> That number is purely a function of available developer time.

We already have this situation.  There are many issues filed that nobody
is actively working on.  So when we say todo list we don't mean todo as
in we know exactly when we're going to do it.  Todo as in, yeah we
really should do that, but we don't necessarily know when.

In the end we keep our issue tracker filled with valid data, that is
much more manageable and useful.  How many times have you tried to
search a projects issue tracker/bug database only to find half a dozen
entries all on the same issue, ending up having no idea which one to add
that vital piece of information to...

Which is what leads us to our big note asking people to follow our
process.  It works for us, it may not work for all projects.  Sure some
people get a little overjealzous when responding to the issues that
shouldn't have been opened.  But remember, we're the ones that have to
maintain that database, and we're the consumers of the database that you
want to be the most happy with it, so it's probably best to defer to our
requests on how to use it.

-- 
Ben Reser <be...@reser.org>
http://ben.reser.org

"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org