This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNATS web interface unusable


On Fri, 29 Mar 2002, Craig Rodrigues wrote:

> I don't know why people want to to design a big state machine
> for dealing with bug submissions to the GCC project.

We want to design a *small* one - using the ideas from the Bugzilla system
where they are useful (e.g. more finegrained ways of closing bugs, FIXED /
INVALID / ...), and ideas from GNATS where they are useful (e.g. the
"feedback" state).  My understanding was the Bugzilla was fully
configurable and so this just needs appropriate details in a configuration
file (and the conversion script).

> All the other projects I've seen which use Bugzilla have been
> satisfied with the defaults in Bugzilla, and have been able
> to move on with their projects...and their lives.

It has already been stated that Red Hat's Bugzilla adds a state
corresponding to "feedback", so this is not the case.

The Bugzilla defaults for resolving bug reports - RESOLVED when fixed,
VERIFIED when QA have verified something's fixed, CLOSED when the product
has shipped - presuppose a QA structure that isn't present for GCC.  This
isn't designing a big state machine, it's reducing to a *smaller* one that
reflects GCC's processes better.

The details of the conversion need to be got right before the final 
production conversion; if there isn't consensus on any aspect of the 
conversion, then fields should probably be added to carry forward the 
corresponding fields from GNATS, so the information isn't lost and can be 
used for future adjustments.  (E.g. the conversion isn't currently 
preserving the "Class" information, nor the full version number.  I don't 
know if there's agreement on the usefulness of "Class", but the full 
version clearly should be kept.  (And the mapping to the summary list of 
versions should distinguish 2.96 from 2.96 (redhat).))

> When GNATS was first implemented for the GCC project, was
> a big state machine designed for the submission of bug reports,
> or did someone just plop it on a server, accept the defaults with
> a few tweaks  to get it going, and let it run?  Be honest now.....

GNATS was a uniform improvement on the previous system (of mail to
gcc-bugs).  Bugzilla is supposed to be a uniform improvement on GNATS -
i.e., should do everything as well as GNATS, and many things better.  It
does do most things better, including both the web and email interfaces.  
It's just left to ensure that the details of conversion and database
structure are uniformly as good - that meaningful distinctions present in
the current system aren't lost in the new one (while useful new features,
such as DUPLICATE and dependencies, are made use of).

> - set it up somewhere, try it out with the defaults.  Customize config
>   files and minor tweaks to get it going. (Dan Berlin has already done this
>   and it is at: http://www.dberlin.org/bugzilla-2.14/)

- Get it in CVS.  I'm sure there are useful improvements going on all the
time, but with the configuration not visible in CVS (and so commit
messages going by on mailing lists, etc.) I can't see what's being
improved, or whether a particular desired improvement has been made
without testing it again.

We encourage branches rather than private trees for major GCC
developments.  Much the same applies here.

> - if everything works, set it up on gcc.gnu.org, modify the appropriate web

- In CVS.  The existing GNATS configuration files aren't in CVS; this is a
nuisance when trying to work out why or when GNATS broke in some
particular way.  (Though the GNATSweb script is in CVS.)  In general
configuration, scripts, etc., should always be in CVS - for visibility,
for version control and so anyone can work on them.

>   pages, documentation, scripts, etc., and let it run!

- Again, documentation is important simply for reviewing the test system.  
Now the SC have given the go-ahead, can we see the proposed changes to the
web pages (all of them that mention GNATS) and the manual (bugreport.texi
and sourcebuild.texi both mention GNATS) to describe the new system?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]