Robert Collins wrote:
> On Wed, 2007-04-25 at 07:00 +0000, Russel Winder wrote:
>> PS I hope that this thread is not inappropriate, I was talking this
>> through with someone I know and their comment was "File a bug." So I
>> did.
>
> Bugs are good because they prevent the issue being lost.
This is true, but bugs are bad when they refer to issues that aren't
bugs, and don't demonstrate unambiguously-incorrect behavior. Making a
bug from a feature request is an assertion that "bzr is broken because
it doesn't meet my needs" and "this feature is the only acceptable way
for bzr to meet my needs".
This could be fixed by making Malone an *issue tracker* rather than a
bug tracker. Then this could be a feature request, or better yet, a
*user need*: "provide a sane workflow for people who use SVN to work
with binary files".
> I think for this though we should have a discussion on the mailing list
> to get a broader set of input.
That is another problem with just using a bugtracker. Feature requests
are often improved by list discussion,
I can imagine setting up Bundle Buggy to track "Feature requests" as
well as merge requests. They would be displayed in separate views. We
can make sure that non-subscribers can submit feature requests. That
would prevent requests from getting lost, and will keep feature requests
on the mailing list. What do you think of that idea?
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Collins wrote:
> On Wed, 2007-04-25 at 07:00 +0000, Russel Winder wrote:
>> PS I hope that this thread is not inappropriate, I was talking this
>> through with someone I know and their comment was "File a bug." So I
>> did.
>
> Bugs are good because they prevent the issue being lost.
This is true, but bugs are bad when they refer to issues that aren't incorrect behavior. Making a
bugs, and don't demonstrate unambiguously-
bug from a feature request is an assertion that "bzr is broken because
it doesn't meet my needs" and "this feature is the only acceptable way
for bzr to meet my needs".
This could be fixed by making Malone an *issue tracker* rather than a
bug tracker. Then this could be a feature request, or better yet, a
*user need*: "provide a sane workflow for people who use SVN to work
with binary files".
> I think for this though we should have a discussion on the mailing list
> to get a broader set of input.
That is another problem with just using a bugtracker. Feature requests
are often improved by list discussion,
I can imagine setting up Bundle Buggy to track "Feature requests" as
well as merge requests. They would be displayed in separate views. We
can make sure that non-subscribers can submit feature requests. That
would prevent requests from getting lost, and will keep feature requests
on the mailing list. What do you think of that idea?
Aaron enigmail. mozdev. org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFGMLNl0F+ nu1YWqI0RAl2CAJ 4jj7iQ39YPDMlEC /iFSYkFGa8KJwCd Hj6T 7Udz47l63DaLkoQ =
LYYKnUr+
=xYzN
-----END PGP SIGNATURE-----