Something to look into. That might actually. E something we can configure correctly rather than also giving admin. On Fri, Apr 14, 2017 at 3:25 PM Tomás Fernández Löbbe <tomasflo...@gmail.com> wrote:
> Isn't the PMC group required to see issues with security level "private"? > > On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett <casstarg...@gmail.com > > 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 <erickerick...@gmail.com> >> 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 <markrmil...@gmail.com> >> 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 < >> erickerick...@gmail.com> >> >> 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 <markrmil...@gmail.com> >> >>> 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 >> >>> > <erickerick...@gmail.com> >> >>> > 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 >> >>> >> <erickerick...@gmail.com> >> >>> >> 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 < >> markrmil...@gmail.com> >> >>> >> > 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 < >> markrmil...@gmail.com> >> >>> >> >> 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 >> >>> >> >>> <markrmil...@gmail.com> >> >>> >> >>> 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 >> >>> >> >>>> <markrmil...@gmail.com> >> >>> >> >>>> wrote: >> >>> >> >>>>> >> >>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett >> >>> >> >>>>> <casstarg...@gmail.com> 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 >> >>> >> >>>>>> <markrmil...@gmail.com> >> >>> >> >>>>>> 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: dev-unsubscr...@lucene.apache.org >> >>> >> >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >>>>>> >> >>> >> >>>>> -- >> >>> >> >>>>> - Mark >> >>> >> >>>>> about.me/markrmiller >> >>> >> >>>> >> >>> >> >>>> -- >> >>> >> >>>> - Mark >> >>> >> >>>> about.me/markrmiller >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> - Mark >> >>> >> >>> about.me/markrmiller >> >>> >> >> >> >>> >> >> -- >> >>> >> >> - Mark >> >>> >> >> about.me/markrmiller >> >>> >> >> >>> >> >> --------------------------------------------------------------------- >> >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> >>> > -- >> >>> > - Mark >> >>> > about.me/markrmiller >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>> >> >> -- >> >> - Mark >> >> about.me/markrmiller >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- - Mark about.me/markrmiller
