You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2016/04/14 00:40:39 UTC
post-branch_6x Jira version renaming(s) got overlooked?
I just noticed that most of the (older) jira's listed in 6.0's CHANGES.txt
files are still showing up in Jira as being fixed in "master"
Examples...
https://issues.apache.org/jira/browse/LUCENE-5950
https://issues.apache.org/jira/browse/LUCENE-6631
https://issues.apache.org/jira/browse/SOLR-3085
https://issues.apache.org/jira/browse/SOLR-7560
Only some of the more recent issues, that were resolved after branch_6x /
(and/or branch_6_0) was created, thus people deliberately backported
and deliberately marked them as fixed in 6.0 have the newer "6.0" fix
version...
https://issues.apache.org/jira/browse/LUCENE-7056
https://issues.apache.org/jira/browse/SOLR-8831
my recollection is that part of the release process for creating a new X.0
release is to rename the "master" version in Jira to "X.0" and re-add a
new "master" version -- but it looks like that never happened for 6.0 (is
it not documented as part of the release process?) and insstead entirely
new "6.0" jira versions were added.
In any case: it seems like we now need to bulk edit *most* of the
issues currently labeled "Fixed: master" in both the LUCENE and SOLR jira
projects, so they are "Fixed: 6.0" (i say *most* because obviously we'll
need to audit the issues resolved & committed only to master after the
6x branch was created and leave them alone) .. sound right?
(we probably shouldn't remove/replace the existing "6.0" versions in
Jira, because we already have issues marked as "Affects: 6.0")
Or am i completley missunderstanding the situation?
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
I've filed LUCENE-7271 to track the work that needs done, and included
full details on exactly what i plan to do.
I'll try to get started sometime tomorrow unless anyone chimes in on that
jira with concerns/suggested improvements to the plan...
https://issues.apache.org/jira/browse/LUCENE-7271
: Date: Fri, 29 Apr 2016 15:41:06 -0700 (MST)
: From: Chris Hostetter <ho...@fucit.org>
: To: Lucene Dev <de...@lucene.apache.org>
: Subject: Re: post-branch_6x Jira version renaming(s) got overlooked?
:
:
: : OK. I'm not sure you're missing anything. But, I think we'll all know
: : for sure pretty quickly once we're doing it.
:
: That sounds like a ringing vote of confidence!
:
:
: : Do you want help with this? Seems like you have it under control, but
: : if you want to split it somehow, I can help a bit this afternoon.
:
: Not just yet thanks ... i want to mull it a bit more, and maybe start on
: it monday.
:
: One thing i'll definitely do before i start changing anything is use the
: "Bulk Edit" feature to add *comments* with 2 new unique magic strings to
: all of the issues that match the queries against the current "master" or
: "6.0"
:
: Once thats done then we should be able to merge the versions with
: confidence, because we should always be able to do searches to find those
: 2 distinct sets again if something gets fucked up and needs manually fixed
: -- and the various audits we need/want to do can be done after the fact
: using searches on those magic strings.
:
: when it's time for auditing those ~100 6.1 jiras it might be worth
: splitting up the work, but it should go pretty quick.
:
:
: :
: : On Fri, Apr 29, 2016 at 2:47 PM, Chris Hostetter
: : <ho...@fucit.org> wrote:
: : >
: : > : Yeah, good point, I forgot about the permutations with backported issues.
: : > :
: : > : But it's not just master + 6.1, it's also master + 6.0. That's why
: : > : the query I sent out looked for issues that had "master", but not
: : > : either of those versions. If it's marked for 6.0 and also master, then
: : > : it's meant for 7.0 (eventually).
: : >
: : > Not neccessarily -- we have no way of nowing when "master" was put in
: : > fixVersion, so "6.0, master" might mean "commited to master=7.0 and
: : > branch_6x=6.0" or it might mean "commited to master which was then later
: : > forked to branch_6x but then someone also added 6.0 explicitly when
: : > resolving"
: : >
: : > in general, if we're going to merge master->6.0 we don't have to worry
: : > about any issues that *currently* list both -- that wll be resolved when
: : > they merge.
: : >
: : > I'm pretty sure we only have to worry about:
: : >
: : > a) issues that list both "master
: : > + 6.1" and wether that really means "commited to branch_6_0=6.0 and
: : > branch_6x=6.1" or "commited to master=7.0 and branch_6x=6.0" ... which is
: : > why i suggested a manual audit based on jira query.
: : >
: : > b) issues that *should* only list "master" once we are all done ... which
: : > should be a really straight forward audit of the 7.0 CHANGES.txt.
: : >
: : > ...or am i still missing something?
: : >
: : > : generally assumed. We could remove master from all issues that already
: : > : have another fixVersion (except the forward ones, 6.0 and 6.1), and
: : > : then just deal with that list. It's much more manageable:
: : > :
: : > : https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
: : >
: : > how would we remove master from master from those issues? the "Bulk Edit
: : > replaces whole field" problem would force us to remove all fixVersions in
: : > that case wouldn't it?
: : >
: : >
: : >
: : >
: : >
: : > : > : > 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
: : >
: : > -Hoss
: : > http://www.lucidworks.com/
: : >
: : > ---------------------------------------------------------------------
: : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
: : > For additional commands, e-mail: dev-help@lucene.apache.org
: : >
: :
: : ---------------------------------------------------------------------
: : To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
: : For additional commands, e-mail: dev-help@lucene.apache.org
: :
: :
:
: -Hoss
: http://www.lucidworks.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
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
: OK. I'm not sure you're missing anything. But, I think we'll all know
: for sure pretty quickly once we're doing it.
That sounds like a ringing vote of confidence!
: Do you want help with this? Seems like you have it under control, but
: if you want to split it somehow, I can help a bit this afternoon.
Not just yet thanks ... i want to mull it a bit more, and maybe start on
it monday.
One thing i'll definitely do before i start changing anything is use the
"Bulk Edit" feature to add *comments* with 2 new unique magic strings to
all of the issues that match the queries against the current "master" or
"6.0"
Once thats done then we should be able to merge the versions with
confidence, because we should always be able to do searches to find those
2 distinct sets again if something gets fucked up and needs manually fixed
-- and the various audits we need/want to do can be done after the fact
using searches on those magic strings.
when it's time for auditing those ~100 6.1 jiras it might be worth
splitting up the work, but it should go pretty quick.
:
: On Fri, Apr 29, 2016 at 2:47 PM, Chris Hostetter
: <ho...@fucit.org> wrote:
: >
: > : Yeah, good point, I forgot about the permutations with backported issues.
: > :
: > : But it's not just master + 6.1, it's also master + 6.0. That's why
: > : the query I sent out looked for issues that had "master", but not
: > : either of those versions. If it's marked for 6.0 and also master, then
: > : it's meant for 7.0 (eventually).
: >
: > Not neccessarily -- we have no way of nowing when "master" was put in
: > fixVersion, so "6.0, master" might mean "commited to master=7.0 and
: > branch_6x=6.0" or it might mean "commited to master which was then later
: > forked to branch_6x but then someone also added 6.0 explicitly when
: > resolving"
: >
: > in general, if we're going to merge master->6.0 we don't have to worry
: > about any issues that *currently* list both -- that wll be resolved when
: > they merge.
: >
: > I'm pretty sure we only have to worry about:
: >
: > a) issues that list both "master
: > + 6.1" and wether that really means "commited to branch_6_0=6.0 and
: > branch_6x=6.1" or "commited to master=7.0 and branch_6x=6.0" ... which is
: > why i suggested a manual audit based on jira query.
: >
: > b) issues that *should* only list "master" once we are all done ... which
: > should be a really straight forward audit of the 7.0 CHANGES.txt.
: >
: > ...or am i still missing something?
: >
: > : generally assumed. We could remove master from all issues that already
: > : have another fixVersion (except the forward ones, 6.0 and 6.1), and
: > : then just deal with that list. It's much more manageable:
: > :
: > : https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
: >
: > how would we remove master from master from those issues? the "Bulk Edit
: > replaces whole field" problem would force us to remove all fixVersions in
: > that case wouldn't it?
: >
: >
: >
: >
: >
: > : > : > 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
: >
: > -Hoss
: > http://www.lucidworks.com/
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
: > For additional commands, e-mail: dev-help@lucene.apache.org
: >
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
: For additional commands, e-mail: dev-help@lucene.apache.org
:
:
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Cassandra Targett <ca...@gmail.com>.
OK. I'm not sure you're missing anything. But, I think we'll all know
for sure pretty quickly once we're doing it.
Do you want help with this? Seems like you have it under control, but
if you want to split it somehow, I can help a bit this afternoon.
On Fri, Apr 29, 2016 at 2:47 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : Yeah, good point, I forgot about the permutations with backported issues.
> :
> : But it's not just master + 6.1, it's also master + 6.0. That's why
> : the query I sent out looked for issues that had "master", but not
> : either of those versions. If it's marked for 6.0 and also master, then
> : it's meant for 7.0 (eventually).
>
> Not neccessarily -- we have no way of nowing when "master" was put in
> fixVersion, so "6.0, master" might mean "commited to master=7.0 and
> branch_6x=6.0" or it might mean "commited to master which was then later
> forked to branch_6x but then someone also added 6.0 explicitly when
> resolving"
>
> in general, if we're going to merge master->6.0 we don't have to worry
> about any issues that *currently* list both -- that wll be resolved when
> they merge.
>
> I'm pretty sure we only have to worry about:
>
> a) issues that list both "master
> + 6.1" and wether that really means "commited to branch_6_0=6.0 and
> branch_6x=6.1" or "commited to master=7.0 and branch_6x=6.0" ... which is
> why i suggested a manual audit based on jira query.
>
> b) issues that *should* only list "master" once we are all done ... which
> should be a really straight forward audit of the 7.0 CHANGES.txt.
>
> ...or am i still missing something?
>
> : generally assumed. We could remove master from all issues that already
> : have another fixVersion (except the forward ones, 6.0 and 6.1), and
> : then just deal with that list. It's much more manageable:
> :
> : https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
>
> how would we remove master from master from those issues? the "Bulk Edit
> replaces whole field" problem would force us to remove all fixVersions in
> that case wouldn't it?
>
>
>
>
>
> : > : > 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
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
: Yeah, good point, I forgot about the permutations with backported issues.
:
: But it's not just master + 6.1, it's also master + 6.0. That's why
: the query I sent out looked for issues that had "master", but not
: either of those versions. If it's marked for 6.0 and also master, then
: it's meant for 7.0 (eventually).
Not neccessarily -- we have no way of nowing when "master" was put in
fixVersion, so "6.0, master" might mean "commited to master=7.0 and
branch_6x=6.0" or it might mean "commited to master which was then later
forked to branch_6x but then someone also added 6.0 explicitly when
resolving"
in general, if we're going to merge master->6.0 we don't have to worry
about any issues that *currently* list both -- that wll be resolved when
they merge.
I'm pretty sure we only have to worry about:
a) issues that list both "master
+ 6.1" and wether that really means "commited to branch_6_0=6.0 and
branch_6x=6.1" or "commited to master=7.0 and branch_6x=6.0" ... which is
why i suggested a manual audit based on jira query.
b) issues that *should* only list "master" once we are all done ... which
should be a really straight forward audit of the 7.0 CHANGES.txt.
...or am i still missing something?
: generally assumed. We could remove master from all issues that already
: have another fixVersion (except the forward ones, 6.0 and 6.1), and
: then just deal with that list. It's much more manageable:
:
: https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
how would we remove master from master from those issues? the "Bulk Edit
replaces whole field" problem would force us to remove all fixVersions in
that case wouldn't it?
: > : > 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
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Cassandra Targett <ca...@gmail.com>.
Yeah, good point, I forgot about the permutations with backported issues.
But it's not just master + 6.1, it's also master + 6.0. That's why
the query I sent out looked for issues that had "master", but not
either of those versions. If it's marked for 6.0 and also master, then
it's meant for 7.0 (eventually).
David did bring up a good point, though, which is that if it has a
prior version (4.x, 5.x) then, the fact it's also in 5.x or 6.x is
generally assumed. We could remove master from all issues that already
have another fixVersion (except the forward ones, 6.0 and 6.1), and
then just deal with that list. It's much more manageable:
https://issues.apache.org/jira/browse/SOLR-9046?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20not%20in%20releasedVersions()
On Fri, Apr 29, 2016 at 2:18 PM, Chris Hostetter
<ho...@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 <ho...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by David Smiley <da...@gmail.com>.
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 <ho...@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
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
: 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 <ho...@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
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by David Smiley <da...@gmail.com>.
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
mark them with one version number even though I have to commit it to both
branches. Hmm; but a 4x backport would be an additional version number...
maybe we could handle those issues manually?
On Fri, Apr 29, 2016 at 2:11 PM Chris Hostetter <ho...@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
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
: 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
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Cassandra Targett <ca...@gmail.com>.
Is it possible there are 2100 of these?
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
(Obviously this misses Lucene issues, but I assume a similar strategy
would apply. Also, we may want to shift the date back to the cutting
of the 6_x branch.)
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.
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, yeah, what you guys said - it's not going to be super-easy.
On Wed, Apr 27, 2016 at 1:18 PM, Anshum Gupta <an...@anshumgupta.net> wrote:
> Should've replied to this thread ! I've been seeing those as part of the
> 5.5.1 back ports and it confuses me every now and then.
>
> It should've been handled with the 6.0 release so I wasn't sure how to
> handle those so I've been adding the 6.0 fix version to places where I've
> found them but I should've removed the 'master' tag.
> I'll help with the manual auditing and fixing of this once I have the 5.5.1
> RC1 later today.
>
> On Wed, Apr 27, 2016 at 9:59 AM, Chris Hostetter <ho...@fucit.org>
> wrote:
>>
>>
>> Wow ... ok ... so no responses / opinions other then miller, eh?
>>
>> Thats fine ... slience == compliance i guess.
>>
>> I don't see much choice at this point other then a bunch of manual clean
>> up. I'll try to find some time to take a stab at this at some point in
>> the future i guess, not sure when. I'll reply back to this thread if i
>> do, if anyone else beats me to it please reply here as well so we aren't
>> wasting eachothers time.
>>
>>
>>
>> : Date: Thu, 14 Apr 2016 00:15:11 +0000
>> : From: Mark Miller <ma...@gmail.com>
>> : Reply-To: dev@lucene.apache.org
>> : To: Lucene Dev <de...@lucene.apache.org>
>> : Subject: Re: post-branch_6x Jira version renaming(s) got overlooked?
>> :
>> : Yeah, sorry, I saw this too. People kept making 6 and 6.0 releases in
>> JIRA
>> : during 5x. A couple times I removed them because trunk or master is
>> : supposed to be renamed when we release. But those versions kept getting
>> : created again. I figured the rollover was not done right, but with no
>> other
>> : complaints I did not really look. Some people with JiRa admin power had
>> : different ideas.
>> : On Wed, Apr 13, 2016 at 6:40 PM Chris Hostetter
>> <ho...@fucit.org>
>> : wrote:
>> :
>> : >
>> : > I just noticed that most of the (older) jira's listed in 6.0's
>> CHANGES.txt
>> : > files are still showing up in Jira as being fixed in "master"
>> : >
>> : > Examples...
>> : >
>> : > https://issues.apache.org/jira/browse/LUCENE-5950
>> : > https://issues.apache.org/jira/browse/LUCENE-6631
>> : > https://issues.apache.org/jira/browse/SOLR-3085
>> : > https://issues.apache.org/jira/browse/SOLR-7560
>> : >
>> : > Only some of the more recent issues, that were resolved after
>> branch_6x /
>> : > (and/or branch_6_0) was created, thus people deliberately backported
>> : > and deliberately marked them as fixed in 6.0 have the newer "6.0" fix
>> : > version...
>> : >
>> : > https://issues.apache.org/jira/browse/LUCENE-7056
>> : > https://issues.apache.org/jira/browse/SOLR-8831
>> : >
>> : > my recollection is that part of the release process for creating a new
>> X.0
>> : > release is to rename the "master" version in Jira to "X.0" and re-add
>> a
>> : > new "master" version -- but it looks like that never happened for 6.0
>> (is
>> : > it not documented as part of the release process?) and insstead
>> entirely
>> : > new "6.0" jira versions were added.
>> : >
>> : > In any case: it seems like we now need to bulk edit *most* of the
>> : > issues currently labeled "Fixed: master" in both the LUCENE and SOLR
>> jira
>> : > projects, so they are "Fixed: 6.0" (i say *most* because obviously
>> we'll
>> : > need to audit the issues resolved & committed only to master after the
>> : > 6x branch was created and leave them alone) .. sound right?
>> : >
>> : > (we probably shouldn't remove/replace the existing "6.0" versions in
>> : > Jira, because we already have issues marked as "Affects: 6.0")
>> : >
>> : > Or am i completley missunderstanding the situation?
>> : >
>> : >
>> : > -Hoss
>> : > http://www.lucidworks.com/
>> : >
>> : > ---------------------------------------------------------------------
>> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> : > For additional commands, e-mail: dev-help@lucene.apache.org
>> : >
>> : > --
>> : - Mark
>> : about.me/markrmiller
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> Anshum Gupta
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Anshum Gupta <an...@anshumgupta.net>.
Should've replied to this thread ! I've been seeing those as part of the
5.5.1 back ports and it confuses me every now and then.
It should've been handled with the 6.0 release so I wasn't sure how to
handle those so I've been adding the 6.0 fix version to places where I've
found them but I should've removed the 'master' tag.
I'll help with the manual auditing and fixing of this once I have the 5.5.1
RC1 later today.
On Wed, Apr 27, 2016 at 9:59 AM, Chris Hostetter <ho...@fucit.org>
wrote:
>
> Wow ... ok ... so no responses / opinions other then miller, eh?
>
> Thats fine ... slience == compliance i guess.
>
> I don't see much choice at this point other then a bunch of manual clean
> up. I'll try to find some time to take a stab at this at some point in
> the future i guess, not sure when. I'll reply back to this thread if i
> do, if anyone else beats me to it please reply here as well so we aren't
> wasting eachothers time.
>
>
>
> : Date: Thu, 14 Apr 2016 00:15:11 +0000
> : From: Mark Miller <ma...@gmail.com>
> : Reply-To: dev@lucene.apache.org
> : To: Lucene Dev <de...@lucene.apache.org>
> : Subject: Re: post-branch_6x Jira version renaming(s) got overlooked?
> :
> : Yeah, sorry, I saw this too. People kept making 6 and 6.0 releases in
> JIRA
> : during 5x. A couple times I removed them because trunk or master is
> : supposed to be renamed when we release. But those versions kept getting
> : created again. I figured the rollover was not done right, but with no
> other
> : complaints I did not really look. Some people with JiRa admin power had
> : different ideas.
> : On Wed, Apr 13, 2016 at 6:40 PM Chris Hostetter <
> hossman_lucene@fucit.org>
> : wrote:
> :
> : >
> : > I just noticed that most of the (older) jira's listed in 6.0's
> CHANGES.txt
> : > files are still showing up in Jira as being fixed in "master"
> : >
> : > Examples...
> : >
> : > https://issues.apache.org/jira/browse/LUCENE-5950
> : > https://issues.apache.org/jira/browse/LUCENE-6631
> : > https://issues.apache.org/jira/browse/SOLR-3085
> : > https://issues.apache.org/jira/browse/SOLR-7560
> : >
> : > Only some of the more recent issues, that were resolved after
> branch_6x /
> : > (and/or branch_6_0) was created, thus people deliberately backported
> : > and deliberately marked them as fixed in 6.0 have the newer "6.0" fix
> : > version...
> : >
> : > https://issues.apache.org/jira/browse/LUCENE-7056
> : > https://issues.apache.org/jira/browse/SOLR-8831
> : >
> : > my recollection is that part of the release process for creating a new
> X.0
> : > release is to rename the "master" version in Jira to "X.0" and re-add a
> : > new "master" version -- but it looks like that never happened for 6.0
> (is
> : > it not documented as part of the release process?) and insstead
> entirely
> : > new "6.0" jira versions were added.
> : >
> : > In any case: it seems like we now need to bulk edit *most* of the
> : > issues currently labeled "Fixed: master" in both the LUCENE and SOLR
> jira
> : > projects, so they are "Fixed: 6.0" (i say *most* because obviously
> we'll
> : > need to audit the issues resolved & committed only to master after the
> : > 6x branch was created and leave them alone) .. sound right?
> : >
> : > (we probably shouldn't remove/replace the existing "6.0" versions in
> : > Jira, because we already have issues marked as "Affects: 6.0")
> : >
> : > Or am i completley missunderstanding the situation?
> : >
> : >
> : > -Hoss
> : > http://www.lucidworks.com/
> : >
> : > ---------------------------------------------------------------------
> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> : > For additional commands, e-mail: dev-help@lucene.apache.org
> : >
> : > --
> : - Mark
> : about.me/markrmiller
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Anshum Gupta
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Chris Hostetter <ho...@fucit.org>.
Wow ... ok ... so no responses / opinions other then miller, eh?
Thats fine ... slience == compliance i guess.
I don't see much choice at this point other then a bunch of manual clean
up. I'll try to find some time to take a stab at this at some point in
the future i guess, not sure when. I'll reply back to this thread if i
do, if anyone else beats me to it please reply here as well so we aren't
wasting eachothers time.
: Date: Thu, 14 Apr 2016 00:15:11 +0000
: From: Mark Miller <ma...@gmail.com>
: Reply-To: dev@lucene.apache.org
: To: Lucene Dev <de...@lucene.apache.org>
: Subject: Re: post-branch_6x Jira version renaming(s) got overlooked?
:
: Yeah, sorry, I saw this too. People kept making 6 and 6.0 releases in JIRA
: during 5x. A couple times I removed them because trunk or master is
: supposed to be renamed when we release. But those versions kept getting
: created again. I figured the rollover was not done right, but with no other
: complaints I did not really look. Some people with JiRa admin power had
: different ideas.
: On Wed, Apr 13, 2016 at 6:40 PM Chris Hostetter <ho...@fucit.org>
: wrote:
:
: >
: > I just noticed that most of the (older) jira's listed in 6.0's CHANGES.txt
: > files are still showing up in Jira as being fixed in "master"
: >
: > Examples...
: >
: > https://issues.apache.org/jira/browse/LUCENE-5950
: > https://issues.apache.org/jira/browse/LUCENE-6631
: > https://issues.apache.org/jira/browse/SOLR-3085
: > https://issues.apache.org/jira/browse/SOLR-7560
: >
: > Only some of the more recent issues, that were resolved after branch_6x /
: > (and/or branch_6_0) was created, thus people deliberately backported
: > and deliberately marked them as fixed in 6.0 have the newer "6.0" fix
: > version...
: >
: > https://issues.apache.org/jira/browse/LUCENE-7056
: > https://issues.apache.org/jira/browse/SOLR-8831
: >
: > my recollection is that part of the release process for creating a new X.0
: > release is to rename the "master" version in Jira to "X.0" and re-add a
: > new "master" version -- but it looks like that never happened for 6.0 (is
: > it not documented as part of the release process?) and insstead entirely
: > new "6.0" jira versions were added.
: >
: > In any case: it seems like we now need to bulk edit *most* of the
: > issues currently labeled "Fixed: master" in both the LUCENE and SOLR jira
: > projects, so they are "Fixed: 6.0" (i say *most* because obviously we'll
: > need to audit the issues resolved & committed only to master after the
: > 6x branch was created and leave them alone) .. sound right?
: >
: > (we probably shouldn't remove/replace the existing "6.0" versions in
: > Jira, because we already have issues marked as "Affects: 6.0")
: >
: > Or am i completley missunderstanding the situation?
: >
: >
: > -Hoss
: > http://www.lucidworks.com/
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
: > For additional commands, e-mail: dev-help@lucene.apache.org
: >
: > --
: - Mark
: about.me/markrmiller
:
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
Posted by Mark Miller <ma...@gmail.com>.
Yeah, sorry, I saw this too. People kept making 6 and 6.0 releases in JIRA
during 5x. A couple times I removed them because trunk or master is
supposed to be renamed when we release. But those versions kept getting
created again. I figured the rollover was not done right, but with no other
complaints I did not really look. Some people with JiRa admin power had
different ideas.
On Wed, Apr 13, 2016 at 6:40 PM Chris Hostetter <ho...@fucit.org>
wrote:
>
> I just noticed that most of the (older) jira's listed in 6.0's CHANGES.txt
> files are still showing up in Jira as being fixed in "master"
>
> Examples...
>
> https://issues.apache.org/jira/browse/LUCENE-5950
> https://issues.apache.org/jira/browse/LUCENE-6631
> https://issues.apache.org/jira/browse/SOLR-3085
> https://issues.apache.org/jira/browse/SOLR-7560
>
> Only some of the more recent issues, that were resolved after branch_6x /
> (and/or branch_6_0) was created, thus people deliberately backported
> and deliberately marked them as fixed in 6.0 have the newer "6.0" fix
> version...
>
> https://issues.apache.org/jira/browse/LUCENE-7056
> https://issues.apache.org/jira/browse/SOLR-8831
>
> my recollection is that part of the release process for creating a new X.0
> release is to rename the "master" version in Jira to "X.0" and re-add a
> new "master" version -- but it looks like that never happened for 6.0 (is
> it not documented as part of the release process?) and insstead entirely
> new "6.0" jira versions were added.
>
> In any case: it seems like we now need to bulk edit *most* of the
> issues currently labeled "Fixed: master" in both the LUCENE and SOLR jira
> projects, so they are "Fixed: 6.0" (i say *most* because obviously we'll
> need to audit the issues resolved & committed only to master after the
> 6x branch was created and leave them alone) .. sound right?
>
> (we probably shouldn't remove/replace the existing "6.0" versions in
> Jira, because we already have issues marked as "Affects: 6.0")
>
> Or am i completley missunderstanding the situation?
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
about.me/markrmiller