lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <david.w.smi...@gmail.com>
Subject Re: post-branch_6x Jira version renaming(s) got overlooked?
Date Fri, 29 Apr 2016 19:27:51 GMT
Yeah good point; nevermind.  Sorry for the noise.
+1 to your "current favorite idea of doing a jira 'merge versions' and
manually auditing the issues that etc."

On Fri, Apr 29, 2016 at 3:18 PM Chris Hostetter <hossman_lucene@fucit.org>
wrote:

>
> : The biggest problem seems to be that bulk edit to set the version number
> : overrides any *additional* version numbers in those issues (they'd get
> : removed).  Assuming we can set multiple versions in bulk-edit, maybe we
> : only need to do this command once for every 5.x release? -- i.e. find all
> : issues with fix version master & 5.2, then replace it with 6.0 & 5.2.  Or
> : just replace with 5.2 for that matter -- code in 5.x is assumed to be in
> : all versions after (whatever "master" is).  When I close issues, I don't
>
> that doesn't really help for things that currently say "Fix Version: 5.3,
> 5.2.2, master" ... if you are running 5.2.0, it's important to know that
> if you aren't ready to upgrade to 6.0, but you need a fix to that bug, you
> can upgrade to either 5.3 or 5.2.2 -- but it wasn't fixed in 5.2.1.
>
> So just doing one bulk edit for every "5.x, master" pair isn't enough ...
> you can't even do *one* bulk edit for every 5.x.y, you'd have to do one
> bulk edit for every permutation of all possible 5.x.y combos ... Example:
> some bugs are "Fix Version: 5.3.2, 5.5, master, 5.4.1" while other bugs
> are "5.3.2, 5.4, master" (depending on when they were fixed/backported)
> ...
>
> ...all in all this would probably be 10x more tedious then just abandoming
> "master" and manually editing every issue in CHANGES.txt -- which in
> itself would already be more tedious then my current favorite idea of
> doing a jira "merge versions" and manually auditing the ~100 issues that
> already have master+6.1 ... which is probably as tedious as i'm willing to
> volunteer to be at this point (if other people wnat to volutneer for
> something more tedious i'm happy to let them)
>
>
> : On Fri, Apr 29, 2016 at 2:11 PM Chris Hostetter <
> hossman_lucene@fucit.org>
> : wrote:
> :
> : >
> : > : Is it possible there are 2100 of these?
> : >
> : > Possible or not, that's certialy what it looks like (1665 more in
> LUCENE)
> : >
> : > I woke up this morning thinking "Oh wait - doesn't jira have a way to
> : > merge Versions?" ... and the answer is "Yes" so i was going to suggest
> the
> : > following...
> : >
> : > for both the LUCENE and SOLR project...
> : >
> : > 1) Audit the list of Jira's with 'fixVersion=mater AND fixVersion=6.1'
> and
> : > manually remove master from all of them (only ~100 total)
> : > 2) merge "master" into "6.0"
> : > 3) re add a "master" version to Jira
> : > 3) Audit CHANGES.txt and set fixVersion=master on the handful of
> issues in
> : > the 7.0 section
> : >
> : > ...but that was before i really looked at Cassandra's Jira queries...
> : >
> : > : I did the below JIRA query, only in the Solr project, looking for
> : > : Resolved or Closed issues with fixVersion of "master", but not with
> : > : fixVersion of 6.0 nor 6.1, resolved before 8 Apr 2016 (the release
> : > : date of Lucene/Solr 6).
> : > :
> : > :
> : >
> https://issues.apache.org/jira/browse/SOLR-7712?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20!%3D%206.0%20AND%20fixVersion%20!%3D%206.1%20AND%20resolved%20%3C%20%222016%2F04%2F08%22
> : >
> : > ...if you sort by Resolved Date, it becomes really clear that we've
> fucked
> : > up on renaming/dealing with "master" for longer then just the 6.0
> release
> : > ... it seems like s we didn't do something correctly for 5.0 either.
> : >
> : > So i'm kind of at a loss now as to what the optimal solution would be.
> : >
> : > : It seems it would be easier to make some sort of "rename master" sort
> : > : of change and go back and fix the ones that shouldn't be changed
> : > : because they have been finished post-6.0 release, but I'm not seeing
> a
> : > : good way to make a single query for those.
> : >
> : > that kind of fits with my "Merge Version" idea ... but i'm not sure
> if/how
> : > to care about the really old issues 4.x which will start saying "Fixed
> in:
> : > ...,6.0" ... will that confuse people?  Will users see "Fixed in:
> : > 4.0-ALPHA, 6.0" and think there was a regression in 5.x? ... or am i
> just
> : > over thinking things?
> : >
> : >
> : >
> : > The other option: straight up delete "master" so it disappears from
> all of
> : > these issues (we can add a new "master" back later) and then explicitly
> : > add 6.0 to every issue mentioned in the 6.0 CHANGES sections ...
> writting a
> : > little perl script to pull them out and build up a few jira search urls
> : > like "id in (SOLR-3085, SOLR-7560, SOLR-7707, SOLR-7707, ...)"
> wouldn't be
> : > too painful, and once we had those search URLs matches a few hundred
> : > issues each, we can use the "Bulk Edit" to add 6.0...
> : >
> : > ...oh fuck ... right, i forgot about this part...
> : >
> : > : Additionally, and sadly, in JIRA any bulk update to a field
> overwrites
> : > : the existing value in the field. So if the fixVersion is "master" and
> : > : "5.3", then doing a bulk update to "master" only would remove "5.3".
> : >
> : >
> : > ...so i guess i'm back to my "Merge master -> 6.0" idea, and oh well to
> : > any confusion there might be for those really old issues.
> : >
> : >
> : > Anybody have a better suggestion?
> : >
> : >
> : >
> : > -Hoss
> : > http://www.lucidworks.com/
> : >
> : > ---------------------------------------------------------------------
> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> : > For additional commands, e-mail: dev-help@lucene.apache.org
> : >
> : > --
> : Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> : LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> : http://www.solrenterprisesearchserver.com
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Mime
View raw message