Bugzilla for GCC project?

Bugzilla for GCC project?

[Craig Rodrigues]

Hi,

Earlier this year, I had lobbied the GCC project to consider
moving from GNATS to Bugzilla:

http://gcc.gnu.org/ml/gcc/2002-03/msg01841.html
http://gcc.gnu.org/ml/gcc/2002-02/msg00454.html

Bugzilla offers certain benefits over GNATS, such as the ability
to mark duplicate PR's, better support for MIME attachments,
better performance, etc.

Dan Berlin has previously demonstrated that it is quite
possible to migrate the existing GNATS database to a working
Bugzilla system, by setting this up on his dberlin.org server.

The next steps for this migration to take place as I understood
it was to set up a working Bugzilla install on gcc.gnu.org and
place the configuration files under CVS control, so that GCC
project members/administrators can control and configure the settings.

For this step to take place, I was told that installation of Bugzilla
would be conditional on setting up a new machine to host gcc.gnu.org.
As far as I can tell, this has not happened yet.  
I was told in July 2002 that:

- the new hardware failed
- the ISP which hosts gcc.gnu.org was about to go out of business
- Red Hat's IT department was not supportive of the hardware/network
  configuration and administration issues
- no one has time to set up and configure a new machine and Bugzilla

So what are the issues here?  Is it a matter of money?  Is it a lack
of manpower and time?

Do we need to look to another organization to set up and host
the Bugzilla installation?  Which organization should we look to?
Does the FSF have resources available to host a Bugzilla installation
for the GCC project?  Or is there another organization who would
be able to provide the necessary resources?

For example, IBM hosts a Bugzilla installation for the Linux kernel project:
http://bugme.osdl.org/

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

Re: Bugzilla for GCC project?

[Daniel Berlin]

On Thu, 19 Dec 2002, Craig Rodrigues wrote:

> Hi,
>
> Earlier this year, I had lobbied the GCC project to consider
> moving from GNATS to Bugzilla:
>
> http://gcc.gnu.org/ml/gcc/2002-03/msg01841.html
> http://gcc.gnu.org/ml/gcc/2002-02/msg00454.html
>
> Bugzilla offers certain benefits over GNATS, such as the ability
> to mark duplicate PR's, better support for MIME attachments,
> better performance, etc.
>
> Dan Berlin has previously demonstrated that it is quite
> possible to migrate the existing GNATS database to a working
> Bugzilla system, by setting this up on his dberlin.org server.
>

In fact, the longer we go without it, the less code i have to maintain,
because bugzilla keeps getting features i had to "hack" in (Like it will
have customized fields soon, obviating the need for me to have added the
three fields i did everywhere).
> The next steps for this migration to take place as I understood
> it was to set up a working Bugzilla install on gcc.gnu.org and
> place the configuration files under CVS control, so that GCC
> project members/administrators can control and configure the settings.
>
Yup.

> For this step to take place, I was told that installation of Bugzilla
> would be conditional on setting up a new machine to host gcc.gnu.org.
> As far as I can tell, this has not happened yet.
Correct.
> I was told in July 2002 that:
>
> - the new hardware failed
> - the ISP which hosts gcc.gnu.org was about to go out of business
> - Red Hat's IT department was not supportive of the hardware/network
>   configuration and administration issues
> - no one has time to set up and configure a new machine and Bugzilla
>
> So what are the issues here?  Is it a matter of money?  Is it a lack
> of manpower and time?

I have time and manpower to setup  and configure bugzilla on a machine, i
just don't have a machine.

>
> Do we need to look to another organization to set up and host
> the Bugzilla installation?  Which organization should we look to?
> Does the FSF have resources available to host a Bugzilla installation
> for the GCC project?  Or is there another organization who would
> be able to provide the necessary resources?
>
> For example, IBM hosts a Bugzilla installation for the Linux kernel project:
> http://bugme.osdl.org/
>
> Thanks.
> --
> Craig Rodrigues
> http://www.gis.net/~craigr
> rodrigc@attbi.com
>

Re: Bugzilla for GCC project?

[Christopher Faylor]

On Thu, Dec 19, 2002 at 03:36:58PM -0500, Daniel Berlin wrote:
>> - the new hardware failed

We had a disk error which has since been corrected.

>> - the ISP which hosts gcc.gnu.org was about to go out of business

Not a problem any longer.

>> - Red Hat's IT department was not supportive of the hardware/network
>>   configuration and administration issues

The new system is now safely ensconced in Raleigh on Red Hat's hefty
internet connection.  So, it's close to going live.  Probably in January.

Didn't I make this observation recently in the gcc mailing list?

cgf

Re: Bugzilla for GCC project?

[Daniel Berlin]

On Thu, 19 Dec 2002, Christopher Faylor wrote:

> On Thu, Dec 19, 2002 at 03:36:58PM -0500, Daniel Berlin wrote:

Errr, just to be clear, I only wrote the part saying i had time and
manpower, Craig wrote the pieces you've quoted.

> >> - the new hardware failed
>
> We had a disk error which has since been corrected.
>
> >> - the ISP which hosts gcc.gnu.org was about to go out of business
>
> Not a problem any longer.
>
> >> - Red Hat's IT department was not supportive of the hardware/network
> >>   configuration and administration issues
>
> The new system is now safely ensconced in Raleigh on Red Hat's hefty
> internet connection.  So, it's close to going live.  Probably in January.
>
Cool!
> Didn't I make this observation recently in the gcc mailing list?
Dunno.
>
> cgf
>

Re: Bugzilla for GCC project?

[Svein E. Seldal]

> Do we need to look to another organization to set up and host
> the Bugzilla installation?  Which organization should we look to?
> Does the FSF have resources available to host a Bugzilla installation
> for the GCC project?  Or is there another organization who would
> be able to provide the necessary resources?

A suggestion..

The Norwegian University of Technology and Science has donated a 
computer (and site/lines) for GNU mirror. My original intentions was to 
setup a development (CVS) mirror for the gcc&binutils repositories 
(binary mirror of GNU software exists already here).

We are talking about a 850MHz athlon, 256Mb RAM, approx. 40Gb available 
for data, 100Mbit network. However, there is no form for redundancy in 
this computer, no UPS, no RAID, etc. So this might not be the thing for 
you guys...


Svein

Re: Bugzilla for GCC project?

[Kai Henningsen]

dberlin@dberlin.org (Daniel Berlin)  wrote on 19.12.02 in <Pine.LNX.4.50.0212191614220.2782-100000@dberlin.org>:

> On Thu, 19 Dec 2002, Christopher Faylor wrote:

> Errr, just to be clear, I only wrote the part saying i had time and
> manpower, Craig wrote the pieces you've quoted.

> > The new system is now safely ensconced in Raleigh on Red Hat's hefty
> > internet connection.  So, it's close to going live.  Probably in January.

... which, as we know, has now happened.

So ... is the plan still the same? Any vague ideas as to timeframe?  
Inquiring minds and so on ...

MfG Kai

Re: Bugzilla for GCC project?

[David Edelsohn]

>>>>> Kai Henningsen writes:

Kai> So ... is the plan still the same? Any vague ideas as to timeframe?  
Kai> Inquiring minds and so on ...

	Work is progressing.

David

Re: Bugzilla for GCC project?

[Daniel Berlin]

On Monday, January 27, 2003, at 10:40  AM, David Edelsohn wrote:

>>>>>> Kai Henningsen writes:
>
> Kai> So ... is the plan still the same? Any vague ideas as to 
> timeframe?
> Kai> Inquiring minds and so on ...
>
> 	Work is progressing.
>
> David
>
To be more specific, the new sources machine is currently up and 
running, and i've got a database imported on it, as well as making sure 
bugzilla will run on it (I test it on dberlin.org, then copy over the 
bugzilla code)

I'm currently modifying all the help files to make sense in light of 
the changes, and then i'll make sure the gnats email parser and bug 
email appender still work.

If anyone wants to help modify all the help files, i would appreciate 
it, and can give you an account on my machine with access to them.

If you want to see the current bugzilla, it's at 
http://www.dberlin.org/bugzilla-2.17.3/

It won't send out change email if you change a bug, i've temporarily 
disabled that to avoid random people getting bugzilla email due to 
testing. :P

--Dan

Re: Bugzilla for GCC project?

[Joseph S. Myers]

On Mon, 27 Jan 2003, Daniel Berlin wrote:

> If you want to see the current bugzilla, it's at 
> http://www.dberlin.org/bugzilla-2.17.3/

It generally looks fine (and looks better with Lynx than some older
Bugzilla versions - except Lynx complains "Accept invalid cookie
path=/bugzilla-2.17.3/ as a prefix of '/bugzilla-2.17.3'" about it, I
don't know what this is a bug in; GNATSweb also used to have such a
problem, which got fixed).


Residual conversion issues (losing information in the conversion, so 
preferably to be resolved before transition - though as previously 
discussed GNATS is also losing information as long as it runs, the MIME 
headers on messages people send to PRs):

* The full version number string (with the exact compiler date) is still
getting lost in the conversion.  (The specific version numbers listed are
also missing numbers used for head-of-release-branch bug reports - 2.95.4,
3.0.5, 3.1.2, 3.2.2 - as well as 2.95.1.)

* "feedback" PRs show up as RESOLVED/FIXED.  They clearly aren't resolved,
though in the absence of feedback they'll get closed eventually as INVALID
/ WORKSFORME.

* Do people think the information in "Class" (doc-bug, ice-on-legal-code,
...) is useful?  (I don't care much about it, but perhaps it should end up
as a keyword in the new database or something.)


Conversion issues that can be dealt with afterwards but shouldn't be
forgotten (bugs can always be opened in the new database to track them):

+ "suspended" PRs show up as RESOLVED/LATER which means they don't appear
in default searches, even though they are logically open bugs.  Past
discussion suggests they should be kept open but the information about why
they are suspended be kept in other fields, e.g. dependencies.  (Though
the bug I opened for suspended C++ parser bugs to depend on, in the
expectation this transition would be done before the new parser, has been
fixed by the new parser.)

+ What's the logic in which bugs show up as RESOLVED, and which as CLOSED,
and is the distinction useful?  (None show up as VERIFIED, so we probably
don't need that status.)

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

Re: Bugzilla for GCC project?

[Daniel Berlin]

On Monday, January 27, 2003, at 01:56  PM, Joseph S. Myers wrote:

> On Mon, 27 Jan 2003, Daniel Berlin wrote:
>
>> If you want to see the current bugzilla, it's at
>> http://www.dberlin.org/bugzilla-2.17.3/
>
> It generally looks fine (and looks better with Lynx than some older
> Bugzilla versions - except Lynx complains "Accept invalid cookie
> path=/bugzilla-2.17.3/ as a prefix of '/bugzilla-2.17.3'" about it, I
> don't know what this is a bug in; GNATSweb also used to have such a
> problem, which got fixed).

I probably wrote the prefix wrong, it's in the parameters. I just did 
what it said to write.

>
>
> Residual conversion issues (losing information in the conversion, so
> preferably to be resolved before transition - though as previously
> discussed GNATS is also losing information as long as it runs, the MIME
> headers on messages people send to PRs):
>
Sure.

> * The full version number string (with the exact compiler date) is 
> still
> getting lost in the conversion.

Oh yeah, i'll just append it to the report string (since we don't want 
8 million versions listed in the version box).
>   (The specific version numbers listed are
> also missing numbers used for head-of-release-branch bug reports - 
> 2.95.4,
> 3.0.5, 3.1.2, 3.2.2 - as well as 2.95.1.)
>
Do we have an exhaustive list of versions i can use?

I just regex search for every version that popped into my head as 
having seen, so i'm sure i just missed them.
> * "feedback" PRs show up as RESOLVED/FIXED.  They clearly aren't 
> resolved,
> though in the absence of feedback they'll get closed eventually as 
> INVALID
> / WORKSFORME.
Would you rather mark these as UNCONFIRMED, or do you want a WAITING or 
FEEDBACK state?
I've added a WAITING state in anticipation, i'll make it use it in the 
next conversion.
T
> 		
> * Do people think the information in "Class" (doc-bug, 
> ice-on-legal-code,
> ...) is useful?  (I don't care much about it, but perhaps it should 
> end up
> as a keyword in the new database or something.)
>
>
> Conversion issues that can be dealt with afterwards but shouldn't be
> forgotten (bugs can always be opened in the new database to track 
> them):
>
> + "suspended" PRs show up as RESOLVED/LATER which means they don't 
> appear
> in default searches, even though they are logically open bugs.  Past
> discussion suggests they should be kept open but the information about 
> why
> they are suspended be kept in other fields, e.g. dependencies.  (Though
> the bug I opened for suspended C++ parser bugs to depend on, in the
> expectation this transition would be done before the new parser, has 
> been
> fixed by the new parser.)

I'll mark them WAITING.
>
> + What's the logic in which bugs show up as RESOLVED, and which as 
> CLOSED,
> and is the distinction useful?  (None show up as VERIFIED, so we 
> probably
> don't need that status.)
>

VERIFIED is for verified by some qa person. RESOLVED means the 
developer thinks it's fixed now. CLOSED means the bug was fixed and the 
released that fixed it shipped.
In effect, you could archive and remove old closed bugs, but you don't 
want to remove any resolved/verified bugs, since they may be reopened 
if something doesn't really fix the bug.

We *could* use VERIFIED, but i don't think it matters for our purposes, 
since the only time we'd have a distinction is when a developer 
*thinks* a patch fixes a bug, but isn't sure.
I'm not sure that people would use it.
> -- 
> Joseph S. Myers
> jsm28@cam.ac.uk
>

Re: Bugzilla for GCC project?

[Joseph S. Myers]

On Mon, 27 Jan 2003, Daniel Berlin wrote:

> Do we have an exhaustive list of versions i can use?

releases.html, then add one to the patchlevel of the last release on each
branch to get the number for head-of-branch.  But versions before 2.95
probably aren't worth including unless there are many bugs filed for egcs
1.1.2 etc..

releasing.html and branching.html will need to detail where Bugzilla gets
new version numbers (and milestones corresponding to them) added, when new
release branches are made or releases cut.

> Would you rather mark these as UNCONFIRMED, or do you want a WAITING or 
> FEEDBACK state?

Some such WAITING or FEEDBACK state - preferably different from what's
used for "suspended" bugs, so it's easy to do a search for "feedback" bugs
that haven't been touched in three months and so are good candidates for
closing.

> VERIFIED is for verified by some qa person. RESOLVED means the 
> developer thinks it's fixed now. CLOSED means the bug was fixed and the 
> released that fixed it shipped.
> In effect, you could archive and remove old closed bugs, but you don't 
> want to remove any resolved/verified bugs, since they may be reopened 
> if something doesn't really fix the bug.
> 
> We *could* use VERIFIED, but i don't think it matters for our purposes, 
> since the only time we'd have a distinction is when a developer 
> *thinks* a patch fixes a bug, but isn't sure.
> I'm not sure that people would use it.

It's the lack of the QA structure to distinguish these things that's why
we might as well not have these distinctions - but if we do have them, it
will just mean they aren't necessarily used very accurately, and it
shouldn't make much difference to work on GCC bugs either way.  So
probably keep the distinctions if someone wants to use them, otherwise
not.

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