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]
