Re: GNATS web interface unusable

[Phil Edwards <phil at jaj dot com>]

On Thu, Mar 28, 2002 at 09:06:44PM +0000, Joseph S. Myers wrote:
> On Thu, 28 Mar 2002, Phil Edwards wrote:
> > On Thu, Mar 28, 2002 at 05:57:42PM +0000, Joseph S. Myers wrote:
> > > what the equivalent of "suspended" should be,
> > 
> > I don't there there is a single equivalent for this.  Not all "suspended"s
> > are created equal.
> 
> The generic Bugzilla equivalents are LATER and REMIND.  The problem with
> those is that they are resolutions that make a bug count as closed, and so
> not show up on default searches.  Since suspended bugs are genuine bugs
> that haven't been fixed, this is bad - they should show up on default
> searches for open bugs, and count as open.

I think I agree.  Well, perhaps we'll modify bugzilla source to do this.


> They get suspended because it's recognised that they should be fixed, but
> there's a reason to believe that they aren't going to be fixed in the
> short or medium term.

I know what "suspended" means in the general sense; I'm asking for a list
of day-to-day, in-actual-practice examples:  blocked by another bug, needs
a missing feature, waiting for a political FSF decision, whatever.  My guess
is that each of those will, in practice, have different Bugzilla equivalents.


> though with Bugzilla
> it would make sense to start assigning bug numbers to issues where
> dependencies are useful.

That's my thought.  Bugzilla has more granular settings than GNATS does,
AFAICT, and the Mozilla people are using it to track these sorts of things.


> So in general you think "suspended" bugs should simply be treated as
> ordinary open bugs ("NEW") - with additional information there somewhere
> (dependencies, keywords, ...) to indicate the type of suspended nature?

I haven't thought about it in depth.  That's certainly one way to go, and I'd
be willing to see suspended libstdc++-v3 PRs get translated in this fashion.


> > > whether we
> > > want WONTFIX, ...)?
> > 
> > Yes, please.
> 
> Why?  If something's a bug, it should be fixed; if it isn't, it should be
> closed as INVALID or WORKSFORME.

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.

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.


> What's your view on the multiple varieties of resolution RESOLVED /
> VERIFIED / CLOSED in Bugzilla?  Should we attempt that sort of QA, or just 
> have a single CLOSED for when bugs have been fixed?

VERIFIED strikes me as "I can reproduce this bug," not "this bug is fixed."

I don't know about the other two.  How do other Bugzilla-using-projects
distinguish between them?  What does the Mozilla project do?


> 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.

If we want a formal state called FEEDBACK, we can add one.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams