Reviving this old thread because I'm seeing a related issue on JIRA. When going to resolve an issue, I can set fix version to either "7.0" or "master (7.0)"
I don't care which one we use, but having two is confusing and I'm sure will lead to a mistake somewhere down the line. So... what's the consensus? On Tue, Apr 18, 2017 at 9:55 AM, Mark Miller <[email protected]> wrote: > Hossman is the only one that can swear more and get away with it. Pact > with the devil or something. > On Tue, Apr 18, 2017 at 8:41 AM Christine Poerschke (BLOOMBERG/ LONDON) < > [email protected]> wrote: > >> Joining the conversation late here. >> >> I've been using fixVersion 6.x in the honest belief that: >> * that was the done thing (and now i know that it isn't, oops) >> * what is displayed as 6.x now will in future become 6.6 (when 6.6 is >> released) or it will stay 6.x (if there is no 6.6 release) >> * if a 6.x label exists then it can and even should be used (that is not >> so) >> >> Thanks for bringing this up and for fixing the mislabeled issues. >> >> Going forward I'm happy to keep an eye on this type of thing though I >> won't be able to match others on the "would have sworn more" style point >> you mention. >> >> Christine >> >> ----- Original Message ----- >> From: [email protected] >> To: [email protected] >> At: 04/14/17 17:22:44 >> >> 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 >
