incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [PROPOSAL] Bugzilla Cleanup
Date Mon, 20 Feb 2012 17:16:35 GMT
On Sun, Feb 19, 2012 at 6:52 PM, Rob Weir <robweir@apache.org> wrote:

> On Thu, Jan 26, 2012 at 11:34 AM, Rob Weir <robweir@apache.org> 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:
>
>
> https://issues.apache.org/ooo/enter_bug.cgi?product=www&component=AOO+Bugzilla
>
> > 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.
> >
>
> Done.
>
> > 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
> these.
>
> What I did do is make sure that anyone registered with an apache.org
> 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.
>

OK, some clarification here. My userid is my old OpenOffice.org email.
However, I did just change my e-mail preferences to my apache.org email. I
can't really change my userid.

So, does your statement above refer to the *email* address the user has, or
their user id?





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.
> >
>
> Done.
>
> > 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 ooo-issues@incubator.apache.org. 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.
> >
>
> Done.
>
> > 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
>



-- 
----------------------------------------------------------------------------------------
MzK

"Follow your bliss."
         -- attributed to Joseph Campbell

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message