GNATS web interface unusable

GNATS web interface unusable

[David O'Brien]

What the #$*@ does a guest user put as the "Originator:" when using
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?  Nothing I tried was accepted by
the web form, including "guest" which is what the form implied was
correct (gcc  User: guest  Access: viewconf).  Pretty hard to submit a
PR when the form is to hard to use...

-- 
-- David  (obrien@FreeBSD.org)

Re: GNATS web interface unusable

[Craig Rodrigues]

On Thu, Mar 28, 2002 at 08:45:52AM -0800, David O'Brien wrote:
> What the #$*@ does a guest user put as the "Originator:" when using
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?  Nothing I tried was accepted by
> the web form, including "guest" which is what the form implied was
> correct (gcc  User: guest  Access: viewconf).  Pretty hard to submit a
> PR when the form is to hard to use...

Does it work with:

Originator: David O'Brien
Submitter-Id: net

When I have more time, I'd like to work on replacing GNATS with
Bugzilla for the GCC project.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@attbi.com

Re: GNATS web interface unusable

[Daniel Berlin]

On Thu, 28 Mar 2002, Craig Rodrigues wrote:

> On Thu, Mar 28, 2002 at 08:45:52AM -0800, David O'Brien wrote:
> > What the #$*@ does a guest user put as the "Originator:" when using
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?  Nothing I tried was accepted by
> > the web form, including "guest" which is what the form implied was
> > correct (gcc  User: guest  Access: viewconf).  Pretty hard to submit a
> > PR when the form is to hard to use...
> 
> Does it work with:
> 
> Originator: David O'Brien
> Submitter-Id: net
> 
> When I have more time, I'd like to work on replacing GNATS with
> Bugzilla for the GCC project.

I've been updating the db every week, and am just waiting for 2.16 to be 
released to make a bigger stink about switching.
:)

I'm also working on integrating GNOME's bugzilla email interface, which 
supports querying/closing directly from email.

> 

Re: GNATS web interface unusable

[David O'Brien]

On Thu, Mar 28, 2002 at 11:54:49AM -0500, Craig Rodrigues wrote:
> On Thu, Mar 28, 2002 at 08:45:52AM -0800, David O'Brien wrote:
> > What the #$*@ does a guest user put as the "Originator:" when using
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?  Nothing I tried was accepted by
> > the web form, including "guest" which is what the form implied was
> > correct (gcc  User: guest  Access: viewconf).  Pretty hard to submit a
> > PR when the form is to hard to use...
> 
> Does it work with:
> 
> Originator: David O'Brien
> Submitter-Id: net

No.  I tired that also.  It told me Originator not recognized.

Re: GNATS web interface unusable

[Gerald Pfeifer]

On Thu, 28 Mar 2002, David O'Brien wrote:
>> Does it work with:
>>
>> Originator: David O'Brien
>> Submitter-Id: net
> No.  I tired that also.  It told me Originator not recognized.

While that won't solve the problem with the web interface, you might
want to give $prefix/bin/gccbug a try (and, in fact, you'll probably
feel much more "at home" with that one anyway, won't you? :-) )

Gerald

PS: Just a very wild guess, but does the web form work if you omit the
single quote in your name? (That would be embarrassing.)
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GNATS web interface unusable

[Joseph S. Myers]

On Thu, 28 Mar 2002, Daniel Berlin wrote:

> > When I have more time, I'd like to work on replacing GNATS with
> > Bugzilla for the GCC project.
> 
> I've been updating the db every week, and am just waiting for 2.16 to be 
> released to make a bigger stink about switching.

Does anyone else have any comments on the database structure / states and
flow of bugs / ... suggestionss I've raised previously (which states of
bugs we want, what the equivalent of "suspended" should be, whether we
want WONTFIX, ...)?  My previous comments on this are at

http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html

and you said we didn't have agreement on them, but I haven't seen anyone
else comment on them.  Apart from these sorts of issues affecting the
conversion - which must be sorted out before the final conversion and
switch to Bugzilla - it seemed from previous tests that the Bugzilla setup
was fairly ready.

Can the test Bugzilla configuration be moved to gcc.gnu.org, with all the
configuration and conversion scripts in CVS, to make it easier for more
people to work on it and see what work is being done on it?

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

Re: GNATS web interface unusable

[David O'Brien]

On Thu, Mar 28, 2002 at 06:39:19PM +0100, Gerald Pfeifer wrote:
> want to give $prefix/bin/gccbug a try (and, in fact, you'll probably
> feel much more "at home" with that one anyway, won't you? :-) )

After failing at the web interface, I did switch to gccbug.  However,
only my first PR got thru.  My second one came back with this:


 Message-Id: <200203281736.g2SHaVo04581@relay.nuxi.org>
 Received: (qmail 9689 invoked for bounce); 28 Mar 2002 17:36:01 -0000
 Date: 28 Mar 2002 17:36:01 -0000
 From: MAILER-DAEMON@sources.redhat.com
 To: obrien@NUXI.com
 Subject: failure notice
 X-UIDL: ?g?"!1;Q"!4Z$#!@Po!!
 Content-Length: 4564
 Lines: 122
 
 Hi. This is the qmail-send program at sources.redhat.com.
 I'm afraid I wasn't able to deliver your message to the following addresses.
 This is a permanent error; I've given up. Sorry it didn't work out.
 
 <gnats-admin@gcc.gnu.org>:
 Sorry, no mailbox here by that name. (#5.1.1)
 
 --- Below this line is a copy of the message.
 
 Return-Path: <obrien@NUXI.com>
 Received: (qmail 9685 invoked by uid 71); 28 Mar 2002 17:36:01 -0000
 Resent-Date: 28 Mar 2002 17:36:01 -0000
 Resent-Message-ID: <20020328173601.9683.qmail@sources.redhat.com>
 Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer)
 Resent-To: gnats-admin@gcc.gnu.org
 Resent-Reply-To: gcc-gnats@gcc.gnu.org, obrien@freebsd.org
 Received:(qmail 6972 invoked from network); 28 Mar 2002 17:29:07 -0000
 Received: from unknown (HELO dragon.nuxi.com) (66.92.13.169)
   by sources.redhat.com with SMTP; 28 Mar 2002 17:29:07 -0000
 Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1])
	 by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g2SHT5Ym089039
	 for <gcc-gnats@gcc.gnu.org>; Thu, 28 Mar 2002 09:29:05 -0800 (PST)
	 (envelope-from obrien@dragon.nuxi.com)
 Received: (from obrien@localhost)
	 by dragon.nuxi.com (8.12.2/8.12.2/Submit) id g2SHRoXX089028;
	 Thu, 28 Mar 2002 09:27:50 -0800 (PST)
 Message-Id:<200203281727.g2SHRoXX089028@dragon.nuxi.com>
 Date:Thu, 28 Mar 2002 09:27:50 -0800 (PST)
 From: "David O'Brien" <obrien@NUXI.com>
 Reply-To: obrien@freebsd.org
 To: gcc-gnats@gcc.gnu.org
 X-Send-Pr-Version:3.113
 Subject: pending/6083: prototize not buildable

Re: GNATS web interface unusable

[David O'Brien]

On Thu, Mar 28, 2002 at 06:39:19PM +0100, Gerald Pfeifer wrote:
> On Thu, 28 Mar 2002, David O'Brien wrote:
> >> Does it work with:
> >>
> >> Originator: David O'Brien
> >> Submitter-Id: net
> > No.  I tired that also.  It told me Originator not recognized.
...
> PS: Just a very wild guess, but does the web form work if you omit the
> single quote in your name? (That would be embarrassing.)

If that were the case, wouldn't "guest" have been excepted?

Re: GNATS web interface unusable

[Daniel Jacobowitz]

On Thu, Mar 28, 2002 at 10:12:37AM -0800, David O'Brien wrote:
> On Thu, Mar 28, 2002 at 06:39:19PM +0100, Gerald Pfeifer wrote:
> > want to give $prefix/bin/gccbug a try (and, in fact, you'll probably
> > feel much more "at home" with that one anyway, won't you? :-) )
> 
> After failing at the web interface, I did switch to gccbug.  However,
> only my first PR got thru.  My second one came back with this:
> 
> 
>  Message-Id: <200203281736.g2SHaVo04581@relay.nuxi.org>
>  Received: (qmail 9689 invoked for bounce); 28 Mar 2002 17:36:01 -0000
>  Date: 28 Mar 2002 17:36:01 -0000
>  From: MAILER-DAEMON@sources.redhat.com
>  To: obrien@NUXI.com
>  Subject: failure notice
>  X-UIDL: ?g?"!1;Q"!4Z$#!@Po!!
>  Content-Length: 4564
>  Lines: 122
>  
>  Hi. This is the qmail-send program at sources.redhat.com.
>  I'm afraid I wasn't able to deliver your message to the following addresses.
>  This is a permanent error; I've given up. Sorry it didn't work out.
>  
>  <gnats-admin@gcc.gnu.org>:
>  Sorry, no mailbox here by that name. (#5.1.1)

This is the standard gcc.gnu.org response to anything with a malformed
subject line: Forward it to the admin; Oops, no admin.  No one seems to
care.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GNATS web interface unusable

[Phil Edwards]

On Thu, Mar 28, 2002 at 05:57:42PM +0000, Joseph S. Myers wrote:
> what the equivalent of "suspended" should be,

I don't there there is a single equivalent for this.  Not all "suspended"s
are created equal.

For a PR which is suspended because some other bug needs fixing first;
Bugzilla already has a dependancy graph:  bug X can block bug Y, and this
easily viewable in the status for both bug X and bug Y.

Why else do PRs get suspended?  I don't know offhand, but the answer will
provide us a list of other possible Bugzilla states.

This kind of translation won't be automated; we need whoever's responsible
for a PR to look at it and go

    switch (why suspended)
    {
        case some other bug:
            add other bug to bugzilla "blocked" list;
            break;
        case no time to work on it:
            remove name from bugzilla cc list;
            break;
        ...
    }


> whether we
> want WONTFIX, ...)?

Yes, please.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GNATS web interface unusable

[Joseph S. Myers]

On Thu, 28 Mar 2002, Phil Edwards wrote:

> On Thu, Mar 28, 2002 at 05:57:42PM +0000, Joseph S. Myers wrote:
> > what the equivalent of "suspended" should be,
> 
> I don't there there is a single equivalent for this.  Not all "suspended"s
> are created equal.

The generic Bugzilla equivalents are LATER and REMIND.  The problem with
those is that they are resolutions that make a bug count as closed, and so
not show up on default searches.  Since suspended bugs are genuine bugs
that haven't been fixed, this is bad - they should show up on default
searches for open bugs, and count as open.

> For a PR which is suspended because some other bug needs fixing first;
> Bugzilla already has a dependancy graph:  bug X can block bug Y, and this
> easily viewable in the status for both bug X and bug Y.
> 
> Why else do PRs get suspended?  I don't know offhand, but the answer will
> provide us a list of other possible Bugzilla states.

They get suspended because it's recognised that they should be fixed, but
there's a reason to believe that they aren't going to be fixed in the
short or medium term.  They often do depend on a missing feature or
infrastructure change - but such features haven't generally been assigned
bug numbers (or the suspended bug may be the bug that describes the needed
changes, and depending on itself doesn't make sense), though with Bugzilla
it would make sense to start assigning bug numbers to issues where
dependencies are useful.

> This kind of translation won't be automated; we need whoever's responsible
> for a PR to look at it and go

A suspended PR generally may not have someone responsible for it -
suspending a PR may well be accompanied by making it unassigned.

Manual translation seems problematic - there will need to be manual
refinement (using new features provided by Bugzilla better than can be
represented by a simple translation from GNATS) but there should be a
reasonable initial translation.  Of course, if there's a volunteer to 
maintain the data about suspended PRs (for input to the translation 
script) until the actual transition, that manual input is fine.

(If someone creates a bug saying "the new C++ parser should be finished 
and merged to mainline", dependencies on that could be automatically 
created for all suspended "c++" bugs whose synopsis matches "parser" - 
which does cover a fair proportion of the suspended PRs.)

>         case some other bug:
>             add other bug to bugzilla "blocked" list;
>             break;
>         case no time to work on it:
>             remove name from bugzilla cc list;
>             break;

So in general you think "suspended" bugs should simply be treated as
ordinary open bugs ("NEW") - with additional information there somewhere
(dependencies, keywords, ...) to indicate the type of suspended nature?

> > whether we
> > want WONTFIX, ...)?
> 
> Yes, please.

Why?  If something's a bug, it should be fixed; if it isn't, it should be
closed as INVALID or WORKSFORME.  If there's no expectation of a fix in
the medium term, the equivalent of "suspended" would be appropriate - but
as long as something is an unfixed bug, the report should remain open, and
show up in default searches to keep reminding people of its existence,
rather than being treated as resolved when it isn't.

What's your view on the multiple varieties of resolution RESOLVED /
VERIFIED / CLOSED in Bugzilla?  Should we attempt that sort of QA, or just 
have a single CLOSED for when bugs have been fixed?

What should the equivalent of "feedback" be?  Again, the state should 
count as open and show up in default searches - though if feedback isn't 
given, they'll end up closed as INVALID or WORKSFORME.

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

Re: GNATS web interface unusable

[Phil Edwards]

On Thu, Mar 28, 2002 at 09:06:44PM +0000, Joseph S. Myers wrote:
> On Thu, 28 Mar 2002, Phil Edwards wrote:
> > On Thu, Mar 28, 2002 at 05:57:42PM +0000, Joseph S. Myers wrote:
> > > what the equivalent of "suspended" should be,
> > 
> > I don't there there is a single equivalent for this.  Not all "suspended"s
> > are created equal.
> 
> The generic Bugzilla equivalents are LATER and REMIND.  The problem with
> those is that they are resolutions that make a bug count as closed, and so
> not show up on default searches.  Since suspended bugs are genuine bugs
> that haven't been fixed, this is bad - they should show up on default
> searches for open bugs, and count as open.

I think I agree.  Well, perhaps we'll modify bugzilla source to do this.


> They get suspended because it's recognised that they should be fixed, but
> there's a reason to believe that they aren't going to be fixed in the
> short or medium term.

I know what "suspended" means in the general sense; I'm asking for a list
of day-to-day, in-actual-practice examples:  blocked by another bug, needs
a missing feature, waiting for a political FSF decision, whatever.  My guess
is that each of those will, in practice, have different Bugzilla equivalents.


> though with Bugzilla
> it would make sense to start assigning bug numbers to issues where
> dependencies are useful.

That's my thought.  Bugzilla has more granular settings than GNATS does,
AFAICT, and the Mozilla people are using it to track these sorts of things.


> So in general you think "suspended" bugs should simply be treated as
> ordinary open bugs ("NEW") - with additional information there somewhere
> (dependencies, keywords, ...) to indicate the type of suspended nature?

I haven't thought about it in depth.  That's certainly one way to go, and I'd
be willing to see suspended libstdc++-v3 PRs get translated in this fashion.


> > > whether we
> > > want WONTFIX, ...)?
> > 
> > Yes, please.
> 
> Why?  If something's a bug, it should be fixed; if it isn't, it should be
> closed as INVALID or WORKSFORME.

Think about "wishlist" category bugs.  A random example:  somebody asks
for a feature which the FSF doesn't like, or isn't really consistent with
GCC's goals.  We close it with WONTFIX.

Think about "won't fix for /this/ release" bugs.  An example is the
"stdio-synchronized ostreams like cout flush after every character" problem.
This is IIRC addressed in 3.1, but it's a WONTFIX for the 3.0 branch.


> What's your view on the multiple varieties of resolution RESOLVED /
> VERIFIED / CLOSED in Bugzilla?  Should we attempt that sort of QA, or just 
> have a single CLOSED for when bugs have been fixed?

VERIFIED strikes me as "I can reproduce this bug," not "this bug is fixed."

I don't know about the other two.  How do other Bugzilla-using-projects
distinguish between them?  What does the Mozilla project do?


> What should the equivalent of "feedback" be?  Again, the state should 
> count as open and show up in default searches - though if feedback isn't 
> given, they'll end up closed as INVALID or WORKSFORME.

Just leave it as OPEN?  The audit trail / comments are right there.

If we want a formal state called FEEDBACK, we can add one.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GNATS web interface unusable

[Joseph S. Myers]

On Thu, 28 Mar 2002, Phil Edwards wrote:

> Think about "wishlist" category bugs.  A random example:  somebody asks
> for a feature which the FSF doesn't like, or isn't really consistent with
> GCC's goals.  We close it with WONTFIX.

That's INVALID, as not being a bug.  (That may also apply to features we
do want, that we list on the projects web pages rather than as bugs.)

> Think about "won't fix for /this/ release" bugs.  An example is the
> "stdio-synchronized ostreams like cout flush after every character" problem.
> This is IIRC addressed in 3.1, but it's a WONTFIX for the 3.0 branch.

That requires someone to open a separate bug to track it as a 3.0-branch
issue (given that the bug has been fixed for 3.1).  Such a bug could be
DUPLICATE of the bug for 3.1, or FIXED as fixed in 3.1 (after all, bugs
are generally closed as soon as they're fixed on the mainline) and not
under consideration for 3.0 branch.

In general saying "never" for mainline bugs should be avoided - and I
don't see how to ensure people don't use WONTFIX except for requests for
bugs to be fixed on a specific branch.  Perhaps there should be something
similar explicitly called OLDBRANCH, defined as "the bug has been fixed on
the mainline, and does not meet the criteria for fixing on the old branch
the bug requested a fix on, or the old branch has been end-of-lifed
altogether", which it is quite clear makes no sense for mainline bugs.

> > What should the equivalent of "feedback" be?  Again, the state should 
> > count as open and show up in default searches - though if feedback isn't 
> > given, they'll end up closed as INVALID or WORKSFORME.
> 
> Just leave it as OPEN?  The audit trail / comments are right there.

It occurs to me that certain properties of bugs (such as feedback and some
aspects of suspended) could be implemented using Bugzilla keywords (rather
than specific new states).

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

Re: GNATS web interface unusable

[Richard Henderson]

On Thu, Mar 28, 2002 at 05:57:42PM +0000, Joseph S. Myers wrote:
> http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html

I think the NEW/UNCONFIRMED distinction is confusing.  I suppose I
could get used to it, but sort of prefer the ANALYZED state name.

Agree about CLOSED.

While WONTFIX is inappropriate for bugs, and seems odd for enhancement
requests, so INVALID seems odd for enhancement requests as well.  I
wouldn't mind seeing a REJECTED resolution for this situation.



r~

Re: GNATS web interface unusable

[Jakub Jelinek]

On Thu, Mar 28, 2002 at 06:16:11PM -0500, Phil Edwards wrote:
> > What should the equivalent of "feedback" be?  Again, the state should 
> > count as open and show up in default searches - though if feedback isn't 
> > given, they'll end up closed as INVALID or WORKSFORME.
> 
> Just leave it as OPEN?  The audit trail / comments are right there.
> 
> If we want a formal state called FEEDBACK, we can add one.

Red Hat bugzilla uses NEEDINFO state for this.

	Jakub

Re: GNATS web interface unusable

[Tom Tromey]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

Joseph> http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html

I've never understood the use or meaning of `suspended'.  I'm
reluctant to ever put a bug into that state, since it means the bug
just disappears.  I think I'd rather either close a bug ("we won't
ever do this") or just make sure it isn't assigned to any upcoming
milestone ("we'll fix it someday, but it isn't release critical") and
leave it open (actually analyzed, with a note explaining the
situation).

Is there really value in having assigned and reopened be separate?
Can you close and reopen a report without ever assigning it?  Whenever
I close a report I assign it to myself; maybe that should be policy.

I like having analyzed.  I don't understand why reopened needs its own
state.  So I'd say remove reopened, change unconfirmed->new, and
new->analyzed.

Does assigned need to be a state?  A bug could be feedback and
assigned.  I think these are orthogonal.

So I suggest statuses much like Gnats: NEW, ANALYZED, FEEDBACK and
CLOSED; resolutions: FIXED, INVALID, DUPLICATE, WORKSFORME.
Assigned and milestones would be separate axes.


Apparently (and it surprised me), I'm basically looking for Gnats
Plus: Gnats, with some weirdness removed, and with some nice useful
features like duplicates, dependencies, and milestones.

That said, I'm sure I will adapt to whatever system is put in place.
I definitely would like to understand the reasons for all the states
Joseph proposed in his message.

Tom

Re: GNATS web interface unusable

[Mark Mitchell]

--On Thursday, March 28, 2002 11:51:30 PM -0700 Tom Tromey 
<tromey@redhat.com> wrote:

>>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:
>
> Joseph> http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html
>
> I've never understood the use or meaning of `suspended'.

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.

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.

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

My two cents,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GNATS web interface unusable

[Joseph S. Myers]

On Fri, 29 Mar 2002, 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.

We should follow similar rules to other upstream code; change it if
necessary to do what we want, but make the changes add configurability
rather than hardcoding something different, and get them accepted by the
Bugzilla maintainers before applying them locally.

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

Re: GNATS web interface unusable

[Toon Moene]

Tom Tromey wrote:

> >>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

> Joseph> http://gcc.gnu.org/ml/gcc/2002-02/msg00692.html

> I've never understood the use or meaning of `suspended'.  I'm
> reluctant to ever put a bug into that state, since it means the bug
> just disappears.

I personally would only mark "change-requests" (i.e., new features) as
possibly "suspended".

It would be nice to be able to indicate if "suspended" meant {next
release | next maintainer | indefinitely}, but it's better than nothing.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GNATS web interface unusable

[Craig Rodrigues]

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

Re: GNATS web interface unusable

[Daniel Berlin]

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

Re: GNATS web interface unusable

[Joseph S. Myers]

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

Re: GNATS web interface unusable

[Gerald Pfeifer]

On Sat, 30 Mar 2002, Joseph S. Myers wrote:
> - Get it in CVS. [...]

Agreed.  Daniel, the question is whether we simply want to add this to the
wwwdocs module or make this a new module -- cgi-bin's definitely should go
into wwwdocs (unless we want a separate directory for Bugzillas cgi-bins).

Concerning timing, I don't know, that probably mostly depends on how much
time Daniel can afford, and when...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/