Re: GNU GNATS 4.0 beta1 released (fwd)

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

On Sat, 12 Jan 2002, Daniel Berlin wrote:

> I thought this type of decision was made by the SC, not RMS?

I get the impression that some things are done by RMS asking the SC in
secret to do something (rather than RMS raising issues of concern on the
public lists).

> What do you mean by "automatic verfication of bugs"

Storing a testcase in a bug report in a structured way so that it can be
tested against different compiler versions and platforms.  Where a problem
has been verified and a testcase is in the testsuite, that suffices - but
if we can have the bug-reporting tool make it easy enough to provide a
testcase and details of what is considered right/wrong behaviour, it
should be possible for the bug tracking system, on receipt, to check
whether the problem still occurs, and say, e.g., "yes, your problem exists
in 3.1.1, but current mainline behaves like you say it should" (and put
that information in the bug report, so maintainers can then decide whether
it needs a fix for 3.1.2, given details of when it occurs already there).

Related would be making GCC automatically produce a .i file, along with a
nicely formatted list of compiler options, when an ICE occurs, to assist
in bug reporting.

>  keeping
> > track of a bug's status in multiple GCC versions,
> You can use meta-bugs to do this, having one meta bug for the bug that 
> depends on the seperate bugs for each version it occurs in.
> This is also easy to do (at least, i've got a patch installed in the 
> bugzilla i've been working on that makes it easy to do) from an interface 
> standpoint. You can simply select a bunch of bugs, and click a button to 
> have it create a bug that depends on all of those bugs.

Using multiple bugs seems a rather confusing way of doing things.  A user 
may want to know the answer to the questions, for a given bug (meaning 
conceptually some problem with GCC, rather than a structure in a bug 
reporting system), having found a number for it: does this bug exist in 
2.95.3, does it exist in 3.0.3, does it exist on mainline, is it 
considered necessary to fix in 3.0.4, ....  Essentially, clsoing a bug 
because it is "fixed" does not provide all the structured information that 
would be useful; while a normal case will be to close for a fix on the 
mainline (with no intention to fix on old release branches), there are 
sets of versions (versions with the bug; versions with it fixed; versions 
with it latent (code problem present, testcase doesn't show it); versions 
with it irrelevant (necessary features not yet in GCC)); and the first 
three include both past and prospective future versions (not necessary to 
fix by then; fix it by then; disable the optimisation/code paths with 
problems for that version).  Users ought to be able to query these sets, 
and know e.g. what known bugs there are in 3.0.3 that are fixed in 3.1, 
and what are there that are worked around in 3.1.

Maybe no bug tracking systems fully support keeping track of independent
information about a bug's status in many versions like that, maybe it
wouldn't be practical to get such accurate information into the system,
and no doubt Bugzilla's dependencies make it easier to achieve much of the
effect, but it seems that it would be useful in principle to track such
information.

> Using one bug for multiple versions is not really a good idea, because you 
> end up duplicating so much info (you may consider it not useful for a 
> release 3.0, but want to fix it for 3.1, so you'd need to also include 
> target milestones, etc, in this single bug. You'd also want to be able to 

Yes.  A single bug, I think, should represent a single problem in GCC, and
for the same bug we can consider both "should this be fixed in 3.1.2?" and
"should this be fixed in 3.2?".  In certain cases there could be multiple
milestones, but I think they can be ordered to avoid that: if something
should be fixed in a release branch, this implies it should also be fixed
at the next mainline milestone, and the next milestone on each later
release branch, if it hasn't been already.

> fix it in two different ways (disabling on a branch, doing the work on 
> the mainline), so you wouldn't want discussion and whatnot of each fix 
> getting in the way of the other).

I don't see the discussion getting in the way more than discussion of
multiple bugs does on gcc-bugs.  The same discussion of the issues around
the bug branches out, and leads naturally to possible solutions with
different levels of risk and cleanliness; splitting them seems artificial.

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