Re: post-branch_6x Jira version renaming(s) got overlooked?
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 <hossman_luc...@fucit.org> : To: Lucene Dev <dev@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 : : <hossman_luc...@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-unsubscr...@lucene.apache.org : : > For additional commands, e-mail: dev-h...@lucene.apache.org : : > : : : : -
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 :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-unsubscr...@lucene.apache.org : > For additional commands, e-mail: dev-h...@lucene.apache.org : > : : - : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : For additional commands, e-mail: dev-h...@lucene.apache.org : : -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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. 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 Hostetterwrote: > > : 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
: 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 Hostetterwrote: > > : 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 > : 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
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 Hostetterwrote: > > : 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_luc...@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...
Re: post-branch_6x Jira version renaming(s) got overlooked?
: 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: 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? : > : >
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 Hostetterwrote: > > : 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@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?
: 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 <ans...@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 <hossman_luc...@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 + >> : From: Mark Miller <markrmil...@gmail.com> >> : Reply-To: dev@lucene.apache.org >> : To: Lucene Dev <dev@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_luc...@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
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 <hossman_luc...@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 + > : From: Mark Miller <markrmil...@gmail.com> > : Reply-To: dev@lucene.apache.org > : To: Lucene Dev <dev@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_luc...@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-unsubscr...@lucene.apache.org > : > For additional commands, e-mail: dev-h...@lucene.apache.org > : > > : > -- > : - Mark > : about.me/markrmiller > : > > -Hoss > http://www.lucidworks.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Anshum Gupta
Re: post-branch_6x Jira version renaming(s) got overlooked?
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 + : From: Mark Miller <markrmil...@gmail.com> : Reply-To: dev@lucene.apache.org : To: Lucene Dev <dev@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_luc...@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-unsubscr...@lucene.apache.org : > For additional commands, e-mail: dev-h...@lucene.apache.org : > : > -- : - Mark : about.me/markrmiller : -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
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 Hostetterwrote: > > 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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- - Mark about.me/markrmiller
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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org