openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Mon, 20 Feb 2012 02:52:08 GMT
On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <> wrote:
> I'd like to make some changes to our bug tracker, to make it more
> user-friendly.  Since these changes are not easily reversible, I'd
> like to describe them first, to see if anyone has objections.

Finally done with this.  It was weeks of work.  Some of this was
delayed due to bugs in BZ 4.0.0.  But with the recent upgrade to BZ
4.0.4 I was able to complete the remainder of this tonight.  It was a
lot of manual clean up and some batch work.  I tried to do the batch
work on weekends and late at night.  Hopefully the notifications were
less disruptive at those times.

If there are additional changes we need, or if anyone notices a
problem, please enter a BZ issue:

> 1) Convert legacy language project "products" into "components" under
> the "native-lang" product.  I'll ensure that all existing bugs
> previously classified under a language project code are reclassified
> into the new structure.


> 2) Create a new "comitters" group in BZ, with additional permissions
> like "editbugs" and "canconfirm"  AOO committers will be added to this
> group, on request. I can't do it automatically, since your BZ login
> might be different than your Apache ID.

I did not change permissions of any existing users with elevated
permissions.  For example, there were 545 legacy users out of many
thousands of users who had "editbugs" permissions.  I have not changed

What I did do is make sure that anyone registered with an
email address would also have editbugs and canconfirm permissions.
That gives any committer/any mentor these same permissions.  If we
want to give these permissions to non-committers, that can also be
done on a case-by-case basis.  That appears to be how how it was done
previously in OOo.

I realize Dave and I have different opinions on how the default
registered user permissions should be set.  I've kept it unchanged for
now.  I'd like those who are actually doing the testing and trying to
develop a QA process in this project determine how best to handle
this.  Any change would impact them most, and I think that their
preferences on this should count far more than what Dave or I think.

> 3) Delete obsolete "products" like bizdev and council.

Since issues were assigned to those products, I did not delete them.
But I did consolidate them under a new product called "obsolete".

> 4) Delete the permission groups associated with the removed products.


> 5) Remove default owners for components.   Most of this information is
> obsolete in any case, with owners being people no longer involved with
> the project.  This will be easy for any comitter to add back, if they
> want to volunteer to own issues in a given category.  But maybe we
> don't even want "owners"?

This is fixed now for the major products/components, with the "default
assignee" now set to This will be for
new issues.  It did not change the currently assigned assignee for
existing issues.

> 6) End result is a much flatter structure.  Instead of hundreds of
> different permission groups corresponding to 100's of different
> components, we have admins, committers, and users.  Admins and
> committers can modify all bugs, regardless of components.


> 7) One objection might be, but what if we have a user who needs to
> regularly modify many bugs, to help move them through the workflow,
> someone who is helping us clean up bugs, correcting classifications,
> verifying issues for us, etc.  Won't they be locked out of doing this
> administrative tasks?  My response is simple:  We should be making
> such users into committers based on that level of contribution.
> 72 hours, etc.
> Regards,
> -Rob

View raw message