Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <1991552089.130740.1426486367427.JavaMail.yahoo@mail.yahoo.com>
References: 
 <CAGHyZ6LAqusyOPyQeyty0T2u1a-OsLUg9vpvUXeJHs9GG6PXQg@mail.gmail.com>
 <1991552089.130740.1426486367427.JavaMail.yahoo@mail.yahoo.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Mon, 16 Mar 2015 10:38:59 -0700
Message-ID: 
 <CA+RK=_B16DG0w9yD5ATkrVx26u4_o3BjnfvY5urAimFqev_keg@mail.gmail.com>
Subject: Re: Jira role cleanup
To: "dev@hbase.apache.org" <dev@hbase.apache.org>,
 lars hofhansl <larsh@apache.org>
Content-Type: multipart/alternative; boundary=089e0122ad10a7532805116b555c

--089e0122ad10a7532805116b555c
Content-Type: text/plain; charset=UTF-8

> I think Jira management should be left to the committers. One can pretty
much mess up a release, and make it hard to account for what's in and
what's not when jiras are changed the around (the ultimate truth can be
reconstructed from the git commit records, but that's tedious).

I agree we should avoid allowing contributors to change JIRA metadata if
this is possible to restrict. Our commit log conventions aren't universally
followed, due to human error, so they are not all tagged with issue
identifiers, or the correct identifier.


On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <larsh@apache.org> wrote:

> Hmm... This is interesting. I think Jira management should be left to the
> committers. One can pretty much mess up a release, and make it hard to
> account for what's in and what's not when jiras are changed the around (the
> ultimate truth can be reconstructed from the git commit records, but that's
> tedious).
> Minimally somebody needs to be able to assign a jira to the person
> providing the patch, if those are committers only that's tedious but OK -
> we've been doing that anyway.Ideally the person could assign an _open_
> issue to him/herself and log work against an issue and change the due data.
> Those seem abilities we could grant to everybody as long as they are
> limited to open issues.
> Beyond that I agree that we should limit this to a known set of people
> (the contributors). Maybe discuss this briefly at the next PMC meeting,
> we're due to have one anyway. I'm willing to host one at Salesforce.
>
> -- Lars
>
>       From: Sean Busbey <busbey@cloudera.com>
>  To: dev <dev@hbase.apache.org>; lars hofhansl <larsh@apache.org>
>  Sent: Sunday, March 15, 2015 9:46 PM
>  Subject: Re: Jira role cleanup
>
> I can make it so that issues can be assigned to non-contributors. Even if
> we don't do that, I believe jira permissions are all about constraining
> current actions, and are not enforced on existing ticketes.
>
> However, the "contributor" role in jira has several other abilities
> associated with it. Right now, in the order they appear in jira:
>
> * edit an issue's due date
> * move issues (between project workflows or projects the user has create
> on)
> * assign issues to other people
> * resolve and reopen issues, assign a fix version (but not close them)
> * manage watchers on an issue
> * log work against an issue
>
> Any of these could also be changed to remove contributors or allow wider
> jira users.
>
> If assignable users can assign to themselves when they don't have the
> assign users permission, then the only one I think we use is "resolve and
> reopen issues." And I don't think I'd want that open to all jira users.
>
> Do we want to have to handle marking issues resolved for folks? It makes
> sense to me, since I usually do that once I push the commit.
>
>
>
>
>
> On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <larsh@apache.org> wrote:
>
> > Not sure what jira does about an assignee when (s)he is removed from the
> > contributors list (I know you have to add a person to the contributors
> list
> > order to assign a jira to them).Other than the committers, we probably
> have
> > at least one jira assigned to a contributor (otherwise why add him/her as
> > contributor).
> > Can we change the jira rules in our space to allow assigning jiras to
> > users even when they're not listed as contributors?
> > We do not have a formal contributor status (why not?), so this list is
> > only needed because of jira.
> > -- Lars
> >
> >      From: Sean Busbey <busbey@cloudera.com>
> >  To: dev <dev@hbase.apache.org>
> >  Sent: Friday, March 13, 2015 9:09 AM
> >  Subject: Re: Jira role cleanup
> >
> > On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> > > +1
> > > I think it would be fine to trim the contributor list too. We can
> always
> > > add people back on demand in order to (re)assign issues.
> > >
> > >
> > I wasn't sure how we generate the list of contributors. But then I
> noticed
> > that we don't link to jira for it like I thought we did[1].
> >
> > How about I make a saved jira query for people who have had jira's
> assigned
> > to them, add a link to that query for our "here are the contributors"
> > section, and then trim off from the role anyone who hasn't been assigned
> an
> > issue in the last year?
> >
> >
> > [1]: http://hbase.apache.org/team-list.html
> >
> >
> >
> > --
> > Sean
> >
> >
> >
> >
>
>
>
> --
> Sean
>
>
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--089e0122ad10a7532805116b555c--