public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Craig Rodrigues <rodrigc@attbi.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: GNATS web interface unusable
Date: Fri, 29 Mar 2002 17:38:00 -0000	[thread overview]
Message-ID: <20020329184926.A8951@attbi.com> (raw)
In-Reply-To: <747220000.1017426886@gandalf.codesourcery.com>; from mark@codesourcery.com on Fri, Mar 29, 2002 at 10:34:46AM -0800

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

  parent reply	other threads:[~2002-03-29 23:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-28  8:59 David O'Brien
2002-03-28  9:01 ` Craig Rodrigues
2002-03-28  9:30   ` Daniel Berlin
2002-03-28 10:14     ` Joseph S. Myers
2002-03-28 13:07       ` Phil Edwards
2002-03-28 14:05         ` Joseph S. Myers
2002-03-28 18:11           ` Phil Edwards
2002-03-28 18:25             ` Joseph S. Myers
2002-03-29  1:37             ` Jakub Jelinek
2002-03-28 22:27       ` Richard Henderson
2002-03-29  1:41       ` Tom Tromey
2002-03-29 12:50         ` Mark Mitchell
2002-03-29 13:37           ` Joseph S. Myers
2002-03-29 17:38           ` Craig Rodrigues [this message]
2002-03-29 18:21             ` Daniel Berlin
2002-03-29 19:09             ` Joseph S. Myers
2002-03-30 11:04               ` Gerald Pfeifer
2002-03-29 17:17         ` Toon Moene
2002-03-28  9:39   ` David O'Brien
2002-03-28 10:13     ` Gerald Pfeifer
2002-03-28 11:07       ` David O'Brien
2002-03-28 11:50         ` Daniel Jacobowitz
2002-03-28 11:21       ` David O'Brien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020329184926.A8951@attbi.com \
    --to=rodrigc@attbi.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).