bq. Beyond that I agree that we should limit this to a known set of people (the contributors). +1
bq. Maybe discuss this briefly at the next PMC meeting +1 too. On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <la...@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 <bus...@cloudera.com> > To: dev <dev@hbase.apache.org>; lars hofhansl <la...@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 <la...@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 <bus...@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 <apurt...@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 > > > >
