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
