[Bug 115990] Re: status should handle the -q (quiet) option like svn

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Mon, 2007-05-21 at 23:28 +0000, Aaron Bentley wrote:

>> This kind of thing is why I want a difference in kind between feature
>> requests and bugs.
> 
> Copying to the list for general discussion, please follow up to bazaar@
> only.
> 
> Well, unless we have a very strict definition of bug like 'causes a
> traceback', I think most things are better classified by what work
> should be done next.

I don't see it that way.  To me, there are two axes: the "useful" axis
and the "broken" axis.

/bin/cat would be an example of a program that is not very useful, but
but is not very broken.  Netscape Communicator 4 would be an example of
the other extreme.

Features (at least, good features) make a project easy to use.  Bugfixes
make it reliable.  They have very different connotations to a user.

Bugs are much less subject to interpretation than features.  In my view,
they're much more important to resolve than feature requests.  A user
who finds that a desired feature is not present can decide whether that
feature is really important.  A user who encounters a bug will lose
confidence in the project.  They will worry that the project has lots of
bugs, and it's impossible to compare bugginess between projects.  Much
more feasible with features.

> Now, with respect to the importance field, I object to conflating the
> importance of the defect in the malone with the workflow that is needed.

Me too.  I think important features should be marked as "important" and
as "features".

> If something is of low import to bzr, it should have an importance that
> matches that. If its so low that we do *not* care if it ever happens,
> then it gets the lowest priority: wishlist.

Full ACK.

> Its my desired that if we sort all bugs by importance

So this is where we run into trouble, because I feel that bugs generally
have much greater urgency than features.  That is, low-priority bugs are
generally more urgent than than low-priority features.  (Unless,
perhaps, the alternative is getting a pie in the face.)

> , and core devs did
> not touch any bug that was not at the top of the list
> (critical->High->Medium->Low->Wishlist),

I also feel that features are harder to allocate to developers than
bugs.  For features, it helps if the developer has an itch to scratch.
That often shapes the quality of the feature.

For bugs, it's really a matter of how hard it is for a given developer
to fix it.  Interest doesn't really enter into it, though shame may.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGXkCh0F+nu1YWqI0RAh1BAJ9649nd8lci7JnjCcNFBS1HWD45ngCeJI2S
x+I0Cx5Ab3qO2QS2mqiAQkE=
=2VFt
-----END PGP SIGNATURE-----