You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Archie Cobbs <ar...@dellroad.org> on 2004/09/25 02:19:09 UTC
Re: [Issue 2058] Let 'svn info' support URL argument
maxb@tigris.org wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2058
>
>
> User maxb changed the following:
>
> What |Old value |New value
> ================================================================================
> Status|NEW |RESOLVED
> --------------------------------------------------------------------------------
> Issue type|ENHANCEMENT |FEATURE
> --------------------------------------------------------------------------------
> Resolution| |INVALID
> --------------------------------------------------------------------------------
> Version|1.0.x |---
> --------------------------------------------------------------------------------
>
>
>
>
> ------- Additional comments from maxb@tigris.org Fri Sep 24 14:21:21 -0700 2004 -------
> See that BOLD RED text on the issue tracker front page?
>
> The stuff asking for matters to be discussed by email *before* being filed in
> the issue tracker?
>
> Right, go, do that.
OK, here it is. Discuss away.
I was my daring assumption that this enhancement request was so simple
that it didn't require a posting before "the community... can fully
understand [my] concern". My apologies for assuming too much and trying
to save everybody a little time.
> And why on earth did you set the version field of this issue to "1.0.x" !?!?!
Because that's the version I'm using?
$ svn --version
svn, version 1.0.4 (r9844)
compiled Jun 4 2004, 17:01:26
Later,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2058] Let 'svn info' support URL argument
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Max Bowsher wrote:
> No problem, we are discussing it now :-)
>
> The thing is, simple though it may seem, there still things that need to
> be discussed, and filed into the issue - we intend our issue tracker to
> be a kind of developer to-do list, which means that where enhancements
> are concerned, we want to have matters of design qualified enough so
> that it's possible to tell how big a job an issue is, and what code it
> is expected to touch.
>
> In this case, "svn info" is, at present, a tool for printing info from
> the WC .svn dir nicely.
>
> Most (but not all) of the information also is valid about a URL, so we
> might be able to get away with overloading the info command with 2
> different features, depending on whether it is given a path or URL - but
> a possibly contentious UI issue like this requires discussion, and
> consensus!
Speaking as the person who originally implemented 'svn info', I'd love
to see it work on URLs, so if someone finds the necesarry tuits then go
for it. It will, of course, be considerably more complex than the
current WC only implentation though. There will have to be a lot of
jumping through hoops to retrieve all the needed info, whereas in the WC
case it's all nicely there for us.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Let 'svn info' support URL argument
Posted by 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
Re: [Issue 2058] Let 'svn info' support URL argument
Posted by Archie Cobbs <ar...@dellroad.org>.
Max Bowsher wrote:
> The thing is, simple though it may seem, there still things that need to be
> discussed, and filed into the issue - we intend our issue tracker to be a
> kind of developer to-do list, which means that where enhancements are
> concerned, we want to have matters of design qualified enough so that it's
> possible to tell how big a job an issue is, and what code it is expected to
> touch.
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.
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
(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.
I realize the current setup is a result of previous frustration
with the high number and/or low quality of bug reports. Perhaps then
(a) would be the right option.
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.
Just my opinion..
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2058] Let 'svn info' support URL argument
Posted by Max Bowsher <ma...@ukf.net>.
Archie Cobbs wrote:
> maxb@tigris.org wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2058
>>
>> ------- Additional comments from maxb@tigris.org Fri Sep 24
>> 14:21:21 -0700
>> 2004 ------- See that BOLD RED text on the issue tracker front page?
>>
>> The stuff asking for matters to be discussed by email *before* being
>> filed in
>> the issue tracker?
>>
>> Right, go, do that.
>
> OK, here it is. Discuss away.
>
> I was my daring assumption that this enhancement request was so simple
> that it didn't require a posting before "the community... can fully
> understand [my] concern". My apologies for assuming too much and trying
> to save everybody a little time.
No problem, we are discussing it now :-)
The thing is, simple though it may seem, there still things that need to be
discussed, and filed into the issue - we intend our issue tracker to be a
kind of developer to-do list, which means that where enhancements are
concerned, we want to have matters of design qualified enough so that it's
possible to tell how big a job an issue is, and what code it is expected to
touch.
In this case, "svn info" is, at present, a tool for printing info from the
WC .svn dir nicely.
Most (but not all) of the information also is valid about a URL, so we might
be able to get away with overloading the info command with 2 different
features, depending on whether it is given a path or URL - but a possibly
contentious UI issue like this requires discussion, and consensus!
>> And why on earth did you set the version field of this issue to "1.0.x"
>> !?!?!
>
> Because that's the version I'm using?
Oh, ok. That both does and does not make sense :-)
The reason for my confusion was that the enhancement applies equally to
1.1.x and trunk too - and it certainly couldn't be added to 1.0.x, which is
a stable branch in critical-bugfix-only mode.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org