Status of Bugzilla?

[Daniel Berlin]

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 
>>> what
>>> happens when.
>>
>> What exactly do you want to see?  Daniel has set up
>> such a system which he mentioned here:
>>
>> http://gcc.gnu.org/ml/gcc/2001-12/msg01113.html
>>
>> and he mentioned adding e-mail input capability here:
>>
>> http://gcc.gnu.org/ml/gcc/2002-01/msg00912.html
>
> (a) What would be the actual contents of the mailing lists using 
> Bugzilla.
> Mailing lists are (from observation, reading hundreds of MB of messages 
> on
> 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
> demonstration.
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 
this way?

>
> (b) The GCC-specific docs - what will replace gnats.html - describing 
> what
> 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 
docs.
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 
> things
> properly.)
>
> --
> Joseph S. Myers
> jsm28@cam.ac.uk