Re: GNATS web interface unusable

[Daniel Berlin <dan at dberlin dot org>]

On Fri, 29 Mar 2002, Craig Rodrigues wrote:

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

Most, however, add some *fields* to suit their particular projects.  Once 
the generic customized field implementation gets put in CVS (it's targeted 
at 2.18 right now, and is quite stable, just needed to cut the list for 
2.16 somewhere), i'd agree we shouldn't be touching the source.

I've only made literally two types of changes to the source.

1. Remove op_sys and rep_platform, add gcchost, gcctarget, gccbuild fields

2. Compress attachments with zlib, since ours are almost always full text,
This is literally a 2 line change to a few source files(one of the lines being 
"use Compress::Zlib" at the top), and reduces the size of the attachments 
database by 70%.

Other than these, there is one hack to merge cc lists when bugs get marked 
duplicates. This is something that is being looked at. Originally, the 
everyone  could only agree on adding the reporter to the duplicate's 
cc, so that's what they did.  I forget what bug number this is on 
bugzilla.mozilla.org.

That's *it*.
The rest is modifications of templates.


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


The precise reason behind templating is so that people don't have to 
modify code to change what it looks like.

--Dan