Dawid: So can we automate this somehow? It's still extra work for the RM and if it could become a one-liner addition to the release process maybe we can make it easier.
On Thu, May 25, 2017 at 8:42 AM, Dawid Weiss <[email protected]> wrote: > It's not really about wanting to tag it 6.x... It's something I got > used to very much and something that helps (me) manage which > branch(es) a given issue has been applied to. When 6.x tag is much > like "next release cut from 6.x". When doing a release 6.[next] I'd > grep for 6.x and bulk-add 6.[next] to all issues currently having 6.x, > then remove 6.x from them (so that they have a constant fix-for, no > branch included anymore). > > This process isn't the only one possible and I've had some discussions > about alternative workflows. I didn't manage to convince my > conversation partners and they failed to convince me, so I think it's > a matter of personal preference. > > The ultimate reference is the changes.txt file anyway (?). > > Dawid > > On Thu, May 25, 2017 at 5:24 PM, Mike Drob <[email protected]> wrote: >> Christine, >> >> Wow, that's fantastic. You can also pass a --grep argument to git directly. >> >> Another problem that just occurred to me though, is that we might need to >> make updates to CHANGES files too. I'm not sure how to automate the check >> for that, since the format can be pretty messy. >> >> Mike >> >> On Thu, May 25, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/ LONDON) >> <[email protected]> wrote: >>> >>> Hi Everyone, >>> >>> Perhaps a little more context would help get us all on the same page re: >>> the "to 6.x or to not 6.x" tag question. >>> >>> === "to 6.x" tag === >>> >>> So, some of us (myself included) for SOLR issues used to tag FixVersion >>> 6.x since the commit was to branch_6x and (at least myself) assumed that >>> when branch_6_7 is cut from branch_6x then the process would somehow >>> magically turn 6.x tags into 6.7 tags, and any subsequently added 6.x tags >>> become 6.8 in future etc. >>> >>> The 6.x to 6.7 transition would be an extra part of the release process >>> and if/since it isn't actually a part of the process then it's >>> retrospectively really really tedious to resolve 6.x to the correct >>> 6.something tag. >>> >>> === "to not 6.x" tag === >>> >>> An alternative is always tag to a specific (future) version i.e. to _not_ >>> 6.x tag anything and to let the released/unreleased categorisation take care >>> of the already-released vs. scheduled-to-be-released difference. >>> >>> === where we are now === >>> >>> There are still some tickets tagged to 6.x and people looking at the >>> version dropdown choices will see 6.x as an existing choice. If/When no >>> tickets are tagged to 6.x anymore then the 6.x choice could be removed from >>> the dropdown choices leaving only specific versions to choose from. >>> >>> Having said all that, turning existing 6.x tagging into specific versions >>> is tedious but not totally impossible, I did a few yesterday using simple >>> git grep lookups: >>> >>> what=LUCENE-NNNN >>> for version in 0 1 2 3 4 5 6 ; do >>> echo branch_6_$version >>> git log --decorate --oneline --graph origin/branch_6_$version | grep $what >>> done >>> >>> Hope that helps? What do people think? >>> >>> Christine >>> >>> From: [email protected] At: 05/25/17 14:08:37 >>> To: [email protected], [email protected], [email protected], >>> [email protected], [email protected], [email protected] >>> Subject: Re: Strange Solr JIRA versions (Lucene too!) >>> >>> Lucene devs, lets get on the same page about this issue. >>> >>> Dawid seems to _want_ to use 6.x >>> >>> https://issues.apache.org/jira/browse/LUCENE-7841?focusedCommentId=16024639&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16024639 >>> Christine and I are the only ones to have commented about this pertaining >>> to LUCENE JIRA issues. Lets have this conversation here, not on >>> LUCENE-7841. >>> >>> ~ David >>> >>> On Thu, May 25, 2017 at 1:28 AM David Smiley <[email protected]> >>> wrote: >>>> >>>> Aha; this problem is a little more than a nuisance... it seems to be why >>>> most of these issues are marked Resolved and not Closed as well. The RM's >>>> release process is to search for JIRA issues with a fix version of the >>>> release version (i.e. 6.6 NOT 6.x). Issues that do not have a real version >>>> then fall through the cracks and remain in a "Resolved" limbo/ambiguity: >>>> >>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved)%20AND%20fixVersion%20%3D%206.x%20ORDER%20BY%20fixVersion%20ASC%2C%20assignee%20ASC >>>> And thus it's unclear to users browsing these issues in JIRA for which >>>> version the issue was released in. >>>> >>>> ~ David >>>> >>>> >>>> On Wed, May 24, 2017 at 11:16 AM David Smiley <[email protected]> >>>> wrote: >>>>> >>>>> It seems this issue applies to Lucene too, and it's more widespread (79 >>>>> issues): >>>>> >>>>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%20branch_6x) >>>>> >>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> 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] >>>>>> >>>>> -- >>>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>>> http://www.solrenterprisesearchserver.com >>>> >>>> -- >>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>>> http://www.solrenterprisesearchserver.com >>> >>> -- >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >>> http://www.solrenterprisesearchserver.com >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
