Isn't the PMC group required to see issues with security level "private"?
On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett <[email protected]> wrote: > I'm also +1 to removing PMC group - I checked and every permission PMC > group has, administrators also have so consolidating those 2 groups > should have no impact on people. > > I'd be happy to have admin access, and I will help keep my eyes out > for problems like this in the future. > > On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson <[email protected]> > wrote: > > bq: my proposal would be to get rid of that PMC group (which is like > > more admins), clear the admin group, and seed it with anyone that > > calls out wanting access > > > > +1 > > > > On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[email protected]> > wrote: > >> bq. Personally I'm fine with not being an administrator as long as I can > >> assign JIRAs to myself and resolve them. > >> > >> I think that is 80-90% of us. The only time I ever use admin is to fix > >> version stuff like this or do a release. I think Jenkins access might > work > >> this way, you have to request it. It would also be great if like the > >> committer role could manage versions, but I couldn't seem to find that > >> feature. > >> > >> But anyway, my proposal would be to get rid of that PMC group (which is > like > >> more admins), clear the admin group, and seed it with anyone that calls > out > >> wanting access, and then give access as requested from there out, extra > >> points for a warning about this 'feature' and managing versions > consistently > >> with the past unless there is discussion. > >> > >> - Mark > >> > >> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[email protected] > > > >> wrote: > >>> > >>> I agree with all your points and would _much_ rather be unable to > >>> screw up even if it meant jumping through another hoop on those rare > >>> occasions when I needed more authority. > >>> > >>> Personally I'm fine with not being an administrator as long as I can > >>> assign JIRAs to myself and resolve them. > >>> > >>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[email protected]> > >>> wrote: > >>> > The problem is not so much notifying people, because no one is > closely > >>> > monitoring this stuff. By the time we ever notice it and attempt to > fix > >>> > it, > >>> > there are 40-200 issues involved. You are not the only one. And I > would > >>> > be > >>> > angry at you! If not for the fact that it's a terrible JIRA issue > that > >>> > did > >>> > not used to be a problem. But, ok, you have learned this JIRA > 'feature' > >>> > is a > >>> > problem. What about those not reading this, what about future > >>> > committers, > >>> > what about you go away for a year and come back having forgotten. The > >>> > JIRA > >>> > issue to fix this in JIRA has tons of votes, but it's also old, so no > >>> > help > >>> > from Atlassian likely any time soon. You can read the comments on the > >>> > bug > >>> > report and lots of people have this problem and hate it. The devs > doing > >>> > it > >>> > here are not special, that's obvious. > >>> > > >>> > I'm not sure why we have so many admins though. Sure, if you do a > >>> > release, > >>> > you want to be able to manage the versions, but a huge number of > >>> > committers > >>> > have not done a release and could request admin when needed. Then we > >>> > could > >>> > grant it, and be like, by the way, careful with your god like powers > to > >>> > create stuff out of thin air without realizing. > >>> > > >>> > Perhaps the other reason most might use admin power is to add > someone, > >>> > but I > >>> > think only a subset of people do that as well currently. > >>> > > >>> > - Mark > >>> > > >>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson > >>> > <[email protected]> > >>> > wrote: > >>> >> > >>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix > >>> >> versions" as "trunk", which is also incorrect. > >>> >> > >>> >> Well, now I know. > >>> >> > >>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson > >>> >> <[email protected]> > >>> >> wrote: > >>> >> > If you look at the "history" tab on the JIRA you can see who set > what > >>> >> > values when. I checked 4-5 of the JIRAS and the person who set > those > >>> >> > has a long record of being very conscientious about changes so I'm > >>> >> > certain it's just an awareness issue, at least for that person. > I'll > >>> >> > ping.... > >>> >> > > >>> >> > Which suggests a way to raise awareness going forward: check the > >>> >> > history and send a message. > >>> >> > > >>> >> > If that doesn't cure it we can consider harsher measures, > although I > >>> >> > don't think forbidding arbitrary labels is "harsh", it's just too > bad > >>> >> > we can't. > >>> >> > > >>> >> > Erick > >>> >> > > >>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller < > [email protected]> > >>> >> > wrote: > >>> >> >> I wish hossman was still more active in this type of thing. He > would > >>> >> >> have > >>> >> >> sworn more and fixed it more meticulously and probably earlier. > Or > >>> >> >> maybe he > >>> >> >> is sick of it after last time. Anyway, I did what I could, > preserved > >>> >> >> the > >>> >> >> proper versions I could, and it's clean again for now. > >>> >> >> > >>> >> >> I'm halfway serious about the admin thing given you can easily > auto > >>> >> >> create > >>> >> >> components and versions by accident. Maybe instead of giving it > to > >>> >> >> everyone > >>> >> >> by default, we should be doing it by request. > >>> >> >> > >>> >> >> - Mark > >>> >> >> > >>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller < > [email protected]> > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people > that > >>> >> >>> add > >>> >> >>> new > >>> >> >>> bad versions in the future ;) This is no fun to cleanup. > >>> >> >>> > >>> >> >>> - Mark > >>> >> >>> > >>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller > >>> >> >>> <[email protected]> > >>> >> >>> wrote: > >>> >> >>>> > >>> >> >>>> Bummer, seems we can't lock this down :( > >>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068 > >>> >> >>>> > >>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller > >>> >> >>>> <[email protected]> > >>> >> >>>> wrote: > >>> >> >>>>> > >>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett > >>> >> >>>>> <[email protected]> wrote: > >>> >> >>>>>> > >>> >> >>>>>> I noticed these the other day also, and had an email > half-wrote > >>> >> >>>>>> that I > >>> >> >>>>>> intended to finish up today. > >>> >> >>>>>> > >>> >> >>>>>> To start, JIRA unfortunately makes this really easy to make a > >>> >> >>>>>> mess > >>> >> >>>>>> of > >>> >> >>>>>> - if you can create or edit an issue, you can just pop in a > new > >>> >> >>>>>> value > >>> >> >>>>>> that gets added to the list of open versions. Editing an > issue > >>> >> >>>>>> is > >>> >> >>>>>> open > >>> >> >>>>>> to lots of folks - committers, contributors, the reporter of > an > >>> >> >>>>>> issue. > >>> >> >>>>>> So, we have high potential for this to be an ongoing problem. > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> Ah, that makes this a lot less baffling I guess. > >>> >> >>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> But, since only committers can commit patches and are thus > the > >>> >> >>>>>> usual > >>> >> >>>>>> resolvers of an issue, committers either aren't paying enough > >>> >> >>>>>> attention to that field when they resolve an issue or there > is > >>> >> >>>>>> confusion/difference of understanding about what that field > is > >>> >> >>>>>> supposed to mean. > >>> >> >>>>>> > >>> >> >>>>>> There are currently 49 issues for Solr that have these > >>> >> >>>>>> "non-standard" > >>> >> >>>>>> versions [1]. Some date back before the most recent 6.5.0 > >>> >> >>>>>> release, > >>> >> >>>>>> which means there are issues fixed in 6.4 and 6.5 (at least) > >>> >> >>>>>> which > >>> >> >>>>>> don't say so in JIRA. > >>> >> >>>>>> > >>> >> >>>>>> This could be really problematic going forward. We need to > agree > >>> >> >>>>>> that > >>> >> >>>>>> when issues are resolved, the fixVersion field is reliable > and > >>> >> >>>>>> means > >>> >> >>>>>> the same thing to everyone. > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> +1! > >>> >> >>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> IMO we should always use the *next* version that makes sense > at > >>> >> >>>>>> that > >>> >> >>>>>> time. So, an issue resolved today would be "6.6" and "master > >>> >> >>>>>> (7.0)". > >>> >> >>>>>> Others may have different points of view on how we should do > >>> >> >>>>>> this, > >>> >> >>>>>> but > >>> >> >>>>>> I think traditionally it's been the way I suggest, so if > there > >>> >> >>>>>> is > >>> >> >>>>>> change desired there, we should discuss it. > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> I agree. > >>> >> >>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> Side note: I know there is some doubt today that 6.6 will > ever > >>> >> >>>>>> exist. > >>> >> >>>>>> However, it will be a lot easier to go through JIRA to remove > >>> >> >>>>>> "6.6" > >>> >> >>>>>> from issues that aren't in 6.x than it will be to review > >>> >> >>>>>> issue-by-issue everything that says "6x" or "6.x" or > >>> >> >>>>>> "branch_6x", > >>> >> >>>>>> etc., and figure out when it was actually released. > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>>> +1. It also matches how we handle CHANGES afaict. > >>> >> >>>>> > >>> >> >>>>> I wish we could disable the auto creating of versions entirely > >>> >> >>>>> somehow, > >>> >> >>>>> but I guess the next best thing is to raise awareness. It's > great > >>> >> >>>>> to > >>> >> >>>>> have > >>> >> >>>>> the correct versions and in the correct ordering. > >>> >> >>>>> > >>> >> >>>>> - Mark > >>> >> >>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> Cassandra > >>> >> >>>>>> > >>> >> >>>>>> [1] Query for JIRA issues: > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> https://issues.apache.org/jira/issues/?jql=project%20% > 3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)% > 20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x) > >>> >> >>>>>> > >>> >> >>>>>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller > >>> >> >>>>>> <[email protected]> > >>> >> >>>>>> wrote: > >>> >> >>>>>> > Who keeps adding strange JIRA release versions? I've > cleaned > >>> >> >>>>>> > up > >>> >> >>>>>> > strange ones > >>> >> >>>>>> > in the past and they keep coming back. > >>> >> >>>>>> > > >>> >> >>>>>> > Why do we have branch6x, 6x and 6.x and trunk? > >>> >> >>>>>> > > >>> >> >>>>>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master > (7.0), > >>> >> >>>>>> > and > >>> >> >>>>>> > I > >>> >> >>>>>> > don't > >>> >> >>>>>> > think we do, who keeps adding these duplicates? Let's come > to > >>> >> >>>>>> > some > >>> >> >>>>>> > sanity > >>> >> >>>>>> > here. > >>> >> >>>>>> > > >>> >> >>>>>> > - Mark > >>> >> >>>>>> > -- > >>> >> >>>>>> > - Mark > >>> >> >>>>>> > about.me/markrmiller > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>>> ------------------------------------------------------------ > --------- > >>> >> >>>>>> To unsubscribe, e-mail: [email protected] > >>> >> >>>>>> For additional commands, e-mail: [email protected] > >>> >> >>>>>> > >>> >> >>>>> -- > >>> >> >>>>> - Mark > >>> >> >>>>> about.me/markrmiller > >>> >> >>>> > >>> >> >>>> -- > >>> >> >>>> - Mark > >>> >> >>>> about.me/markrmiller > >>> >> >>> > >>> >> >>> -- > >>> >> >>> - Mark > >>> >> >>> about.me/markrmiller > >>> >> >> > >>> >> >> -- > >>> >> >> - Mark > >>> >> >> about.me/markrmiller > >>> >> > >>> >> ------------------------------------------------------------ > --------- > >>> >> To unsubscribe, e-mail: [email protected] > >>> >> For additional commands, e-mail: [email protected] > >>> >> > >>> > -- > >>> > - Mark > >>> > about.me/markrmiller > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> -- > >> - Mark > >> about.me/markrmiller > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
