This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Status of Bugzilla?


On Wed, 6 Feb 2002, Daniel Berlin wrote:

> > Do changes to bug categories, priorities, milestones, etc., all generate
> > messages to the list/lists?
> Yes, if you have that set in your preferences.

What's this to do with individual preferences?  They can reasonably
determine whether bug submitters get these messages - but for whether the
messages go to the lists, there should be a global configuration, nothing
to do with any individual's preferences or single bug's configuration.

Do the audit trail messages to the lists show both the old and new field
values, e.g. "milestone changed from 3.2 to 3.3"?

> > Do new attachments (and attachments in newly submitted bug reports with
> > the web interface) get mailed to the lists (as proper MIME attachments),
> > as they should?
> 
> A URL to them gets mailed, rather than sending possibly huge attachments 
> to everyone.
> 
> The URL is direct (IE it takes you to that attachment, rather than the 
> bug)

I'd like to see the attachments going direct to the lists - so simply 
reading through gcc-bugs (maybe even offline) will show all the bug 
reports and comments on them, in a self-contained form that is 
comprehensible without needing external online resources.  A size limit 
here would make sense, something like:

* Attachments under 100k, just send uncompressed as text/whatever.

* Larger attachments under 200k when compressed, send compressed.

* Even larger ones, send URL.

If a bug report isn't self-contained and immediately readable (at present,
including a gnatsweb attachment at all means it isn't immediately
readable, since they aren't sent as MIME) I'm less likely to consider on
seeing the bug report (rather than months later looking through the bug
tracking system) whether it is of interest to attempt a fix to, or
familiar, etc..

> Anyone can submit or view.  People can edit bugs they've submitted or 
> are assigned, and only those,

Edit in what ways?  Adding attachments is something reasonable for
submitters to do, most other changes aren't.

> > Clearly for a production system, the accounts with GNATS write access
> > would map directly to corresponding access for the corresponding accounts
> > (only) in Bugzilla, though not necessarily preserving the GNATS
> > passwords.)
> 
> People need accounts to submit bugs (but accounts also let you do things 
> like save your own set of queries, etc), but it takes 5 seconds to setup 
> in the web interface, and emailing in bug report will auto-create an 
> account for you if necessary, and mail yo uback the password.

Somewhere there must be the manual step to approve the specific people who
get access to edit bugs.  (Which should be scriptable for approving
multiple people etc..)  It needs to be done if/when Bugzilla would be set
up to replace GNATS, for all people with write access to GNATS, and it
needs to be done from time to time later, for people approved by the SC,
from whatever mechanism lies behind the new account form.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]