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
