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, Mar 29, 2002 at 10:34:46AM -0800, Mark Mitchell wrote:
> This is a change of topic, but I believe that one of the single
> biggest guidelines in our use of bugzilla be that we modify the
> bugzilla source code proper somewhere between "not at all" and
> "almost nowhere".  Obviously, hacking up web templates, and using
> the designed interfaces for concocting the right set of states and
> so forth makes sense, but I'd strongly prefer that we not change
> the code itself.

This is the first sensible post I've seen in this thread.

I don't know why people want to to design a big state machine
for dealing with bug submissions to the GCC project.
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.

My thoughts are:
  - no issues tracking system is going to be perfect or make 
    everyone happy or solve every conceivable problem on Earth
    or in the astral planes.
  - Bugzilla has features which are an improvement over the existing
    GNATS system.  These features will improve the situation for
    people who report bugs, and people who analyze bug reports.
    This will make GCC developers more productive, and make GCC
    a better piece of software. 
    
Dan Berlin has done an excellent job on his own, importing
the existing GNATS database into Bugzilla.  I've tried it
out, it Works.  And Dan is adding improvements to it, which
will benefit the GCC project!

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

This is how I think a Bugzilla implementation process for the GCC
project should go:
- 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/)
- if there are heinous bugs in Bugzilla, report them to the Bugzilla project
  and let them fix them, submit patches to them if we know how to fix them
- if everything works, set it up on gcc.gnu.org, modify the appropriate web
  pages, documentation, scripts, etc., and let it run!
- move on to other things in our GCC and non-GCC lives
 
> That will make it harder to move the database to another machine,
> harder to move it no new versions of bugzilla, and so forth and so
> on.

Exactly!

> I'm not sure if we're talking about doing this -- but if we are, I
> think we should be cautious.

More sense!  Now I know why you are the release manager for GCC. :)

> My two cents,

Here's a dollar, keep the change. :)

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@attbi.com


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