hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Jira role cleanup
Date Mon, 16 Mar 2015 18:28:18 GMT
On Mon, Mar 16, 2015 at 11:02 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> bq. Our commit log conventions aren't universally followed, due to human
> error
>
> Going forward, I think we can alleviate this issue with a git hook and a
> regexp.
>

That's a good idea.



> On Mon, Mar 16, 2015 at 10:38 AM, Andrew Purtell <apurtell@apache.org>
> wrote:
>
> > > 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)
> >
>



-- 
Best regards,

   - Andy

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

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