Re: GNATS web interface unusable

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

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.

> For a PR which is suspended because some other bug needs fixing first;
> Bugzilla already has a dependancy graph:  bug X can block bug Y, and this
> easily viewable in the status for both bug X and bug Y.
> 
> Why else do PRs get suspended?  I don't know offhand, but the answer will
> provide us a list of other possible Bugzilla states.

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.  They often do depend on a missing feature or
infrastructure change - but such features haven't generally been assigned
bug numbers (or the suspended bug may be the bug that describes the needed
changes, and depending on itself doesn't make sense), though with Bugzilla
it would make sense to start assigning bug numbers to issues where
dependencies are useful.

> This kind of translation won't be automated; we need whoever's responsible
> for a PR to look at it and go

A suspended PR generally may not have someone responsible for it -
suspending a PR may well be accompanied by making it unassigned.

Manual translation seems problematic - there will need to be manual
refinement (using new features provided by Bugzilla better than can be
represented by a simple translation from GNATS) but there should be a
reasonable initial translation.  Of course, if there's a volunteer to 
maintain the data about suspended PRs (for input to the translation 
script) until the actual transition, that manual input is fine.

(If someone creates a bug saying "the new C++ parser should be finished 
and merged to mainline", dependencies on that could be automatically 
created for all suspended "c++" bugs whose synopsis matches "parser" - 
which does cover a fair proportion of the suspended PRs.)

>         case some other bug:
>             add other bug to bugzilla "blocked" list;
>             break;
>         case no time to work on it:
>             remove name from bugzilla cc list;
>             break;

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?

> > 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.  If there's no expectation of a fix in
the medium term, the equivalent of "suspended" would be appropriate - but
as long as something is an unfixed bug, the report should remain open, and
show up in default searches to keep reminding people of its existence,
rather than being treated as resolved when it isn't.

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?

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.

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