Re: GNATS web interface unusable

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 28 Mar 2002, Phil Edwards wrote:

> Think about "wishlist" category bugs.  A random example:  somebody asks
> for a feature which the FSF doesn't like, or isn't really consistent with
> GCC's goals.  We close it with WONTFIX.

That's INVALID, as not being a bug.  (That may also apply to features we
do want, that we list on the projects web pages rather than as bugs.)

> Think about "won't fix for /this/ release" bugs.  An example is the
> "stdio-synchronized ostreams like cout flush after every character" problem.
> This is IIRC addressed in 3.1, but it's a WONTFIX for the 3.0 branch.

That requires someone to open a separate bug to track it as a 3.0-branch
issue (given that the bug has been fixed for 3.1).  Such a bug could be
DUPLICATE of the bug for 3.1, or FIXED as fixed in 3.1 (after all, bugs
are generally closed as soon as they're fixed on the mainline) and not
under consideration for 3.0 branch.

In general saying "never" for mainline bugs should be avoided - and I
don't see how to ensure people don't use WONTFIX except for requests for
bugs to be fixed on a specific branch.  Perhaps there should be something
similar explicitly called OLDBRANCH, defined as "the bug has been fixed on
the mainline, and does not meet the criteria for fixing on the old branch
the bug requested a fix on, or the old branch has been end-of-lifed
altogether", which it is quite clear makes no sense for mainline bugs.

> > What should the equivalent of "feedback" be?  Again, the state should 
> > count as open and show up in default searches - though if feedback isn't 
> > given, they'll end up closed as INVALID or WORKSFORME.
> 
> Just leave it as OPEN?  The audit trail / comments are right there.

It occurs to me that certain properties of bugs (such as feedback and some
aspects of suspended) could be implemented using Bugzilla keywords (rather
than specific new states).

-- 
Joseph S. Myers
jsm28@cam.ac.uk