Re: Bugzilla read to go live?

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp redhat com> writes:

> Owen Taylor <otaylor redhat com> writes: 
> > I thikk the wording correctly expresses the fact that it is the
> > intersection - if you select both, it will only be visible to people
> > who are both bugzilla maintainers and gnome hackers. How would
> > you improve it?
> 
> I guess I'd do check buttons:
> 
>  [  ]  Must be a gnome hacker to see this bug
>  [  ]  Must be a bugzilla maintainer to see this bug
> 
> But, that's probably painful to implement. Not a huge deal.

Not that bad assuming that I haven't introduced any more
bugs. See if you like the way it is now. 
(Both in  enter_bug.cgi and show_bug.cgi)

> >  - Should we remove the UNCONFIRMED state?
> >  - Should we enable it with only manual confirmation?
> >  - Should we expose the voting mechanism? (ugh)
> >
> 
> I can see how it would be useful to have a QA team that went through and
> checked whether bugs were for real and reproducible, moving them to
> NEW if they were, otherwise to NOTABUG, NEEDINFO, or whatever. Then 
> this same team would move bugs from FIXED to VERIFIED.
> 
> If maintainers are doing everything themselves, then UNCONFIRMED and
> VERIFIED are both useless states probably, since those reflect a QA
> process separate from the maintainer process.
> 
> Anyhow, the logical conclusion of that is "enable with manual
> configuration" if we're going to try to have a QA process, otherwise
> remove UNCONFIRMED and VERIFIED.

Having users verify their own bugs will probably work well. 
For UNCONFIRMED, I think I'll leave it they way it is now for
the moment - you can turn it on for your product if you know
what you are doing, but it is off by default.

Regards,
                                        Owen

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers