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]
