This is the mail archive of the
mailing list for the GCC project.
Re: Status of Bugzilla?
- From: Daniel Berlin <dan at dberlin dot org>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: Craig Rodrigues <rodrigc at mediaone dot net>, <gcc at gcc dot gnu dot org>
- Date: Thu, 7 Feb 2002 11:48:15 -0500
- Subject: Re: Status of Bugzilla?
On Thursday, February 7, 2002, at 11:28 AM, Joseph S. Myers wrote:
> On Wed, 6 Feb 2002, Craig Rodrigues wrote:
>> On Thu, Feb 07, 2002 at 02:48:34AM +0000, Joseph S. Myers wrote:
>>> There are enough complications about the present system that a full
>>> working demonstration of the Bugzilla system would help see exactly
>>> happens when.
>> What exactly do you want to see? Daniel has set up
>> such a system which he mentioned here:
>> and he mentioned adding e-mail input capability here:
> (a) What would be the actual contents of the mailing lists using
> Mailing lists are (from observation, reading hundreds of MB of messages
> the lists since the start of EGCS) a central part of the working of GCC
> development, so I think seeing the overall shape of the list contents
> under Bugzilla is important, which means including the lists in the
As i've said, the lists will get the same change reports humans do.
Thus, all one needs to do is create a new bug, and submit a change, and
you'll see what the messages look like.
There is no magic here.
The appending of comments that the followup email handler does is using
the same routines that doing it on the web does, thus, you can see the
result simply by adding a comment.
Why must I set up email lists when it is much easier to see the result
> (b) The GCC-specific docs - what will replace gnats.html - describing
> the Bugzilla fields mean in a GCC context and the process bug reports in
> Bugzilla will go through. This I do (as docs co-maintainer) claim to
> be a
> blocker: just as with changes to code affecting user-visible behaviour,
> moving to Bugzilla requires the documentation to be ready, and I claim
> that the documentation must be there to evaluate the system
Besides gcc specific fields, and whatever differences in actual bug
process there is, there is nothing wrong with the existing bugzilla
This is not a case of docs not existing.
This is a case of the docs not covering three new fields, and having
information about two fields that no longer exist.
All one needs to do is ignore the references to an OS and platform
field, and imagine there were references to host, build, and target
fields, and you are done.
Claiming the documentation is not ready is not really true.
I'm also not going to write up new documentation until it's decided, one
way or the other, whether we will use it.
I've never seen anyone write documentation for a product before the
product was given a go status by someone higher up.
While i can understand the actual *move* being blocked by docs, saying
you ocan't review it with the docs that are there is silly.
> (Just as when someone submits a proposed new feature in the form of a
> patch without docs and testcases, I say that such a patch isn't worth
> reviewing without the docs needed to say what it's meant to do, and
> sending docs without code would have been better. Working systems and
> code can be interesting to play with, but docs are needed to review
> Joseph S. Myers