[
https://issues.apache.org/jira/browse/LUCENE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-7271:
-----------------------------
Description:
Jira's concept of "Fix Version: master" is currently screwed up, as noted &
discussed in this mailing list thread...
http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0)}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.
I'm using this issue to track this work.
----
Detailed Check list of planned steps:
* S1: Generate a CSV report listing all resolved/closed Jira's with
'fixVersion=master AND fixVersion=6.1'
**
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the
fixVersion set correctly if/when they are resolved in the future
* S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to
every issue currently assocaited with fixVersion=6.0 or fixVersio=master
** The comments will include unique strings based on the the specific query
done, and will map the list back to this issue (ex
{{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
** These comments will serve as a backup plan making it possible to find all
issues affected (by merging jira's concepts of 'master' and '6.0') after the
fact if need be.
** Queries to use for bulk edits:
*** master:
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
*** 6.0:
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
* S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
** This needs to be done distinctly for both LUCENE and SOLR
* S4: Add a new "master (7.0)" version to Jira
** This needs to be done distinctly for both LUCENE and SOLR
* S5: audit every issue in the CSV file from S1 above to determine if/when the
issue should get fixVersion="master (7.0)" *added* to it or fixVersion="6.0"
*removed* from it:
** if it only ever had commits to master (ie: before branch_6x was made on
March 2nd) then no action needed.
** if it has distinct commits to both master after branch_6x was made on March
2nd, then fixVersion="master (7.0)" should definitely be added.
** if it has no commits to branch_6_0, and the only commits to branch_6x are
after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be
removed.
** if there are no obvious commits in the issue comments, then sanity check why
it has any fixVersion at all (can't reproduce? dup? etc...)
* S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with
fixVersion="master (7.0)" on the handful of issues where appropriate in case
they fell through the cracks in S5:
** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new
features
*** currently only 1 jira mentioned in either files in 7.0 section
** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep
'^\+'}} to find changesets on master that were not included in 6.0
*** currently ~40 commits
** before removing fixVersion=6.0 from any of these issues, sanity check if
this is a deprecation type situation (involving diff commits in both 6.0 and
master) in which case fixVersion="master (7.0)" should be _added_ in addition
to fixVersion=6.0
was:
Jira's concept of "Fix Version: master" is currently screwed up, as noted &
discussed in this mailing list thread...
http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0}}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.
I'm using this issue to track this work.
----
Detailed Check list of planned steps:
* S1: Generate a CSV report listing all resolved/closed Jira's with
'fixVersion=master AND fixVersion=6.1'
**
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the
fixVersion set correctly if/when they are resolved in the future
* S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to
every issue currently assocaited with fixVersion=6.0 or fixVersio=master
** The comments will include unique strings based on the the specific query
done, and will map the list back to this issue (ex
{{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
** These comments will serve as a backup plan making it possible to find all
issues affected (by merging jira's concepts of 'master' and '6.0') after the
fact if need be.
** Queries to use for bulk edits:
*** master:
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
*** 6.0:
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
* S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
** This needs to be done distinctly for both LUCENE and SOLR
* S4: Add a new "master (7.0)" version to Jira
** This needs to be done distinctly for both LUCENE and SOLR
* S5: audit every issue in the CSV file from S1 above to determine if the issue
should get fixVersion="master (7.0)" *added* to it
** if it has distinct commits to both master & branch_6x then
fixVersion="master (7.0)" should be added
** if it only ever had commits to master (ie: before branch_6x was made) then
no action needed
** if there are no obvious commits in the issue comments, then sanity check why
it has any fixVersion at all (can't reproduce? dup? etc...)
* S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with
fixVersion="master (7.0)" on the handful of issues where appropraite:
** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new
features
*** currently only 1 jira mentioned in either files in 7.0 section
** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep
'^\+'}} to find changesets on master that were not included in 6.0
*** currently ~40 commits
** before removing fixVersion=6.0 from any of these issues, sanity check if
this is a deprecation type situation (involving diff commits in both 6.0 and
master) in which case fixVersion="master (7.0)" should be _added_ in addition
to fixVersion=6.0
bq. How would this be ever true, considering that the list that you'd generate
would have fix version as master AND 6.1?
It _shouldn't_ ever be true, and it might be paranoied overkill on my part, but
ultimately i'm just trying to cover all the basis in terms of "this issue has
'master' in fixVersion, what was the intent when that was added?"
Imagine this hypothetical timeline...
* master and branch-5x are the only active branches
* commit#1 for JIRA-XXX is commited to master
* JIRA-XXX is marked fixVersion=master and resolved
* branch_6x is created
* branch_6_0 is created
* a bug is noticed in the new functionality added by JIRA-XXX and the issue is
re-opened
* a fix is created and commit#2 is made to master & backported to both
branch-6x and branch_6_0
* *JIRA-XXX is updated to include fixVersion=6.1, but the dev doesn't notice
that 6.0 is missing and doesn't think to add for some reason*
* we merge master -> 6.0, and now the issue only lists fixVersion="6.0, 6.1"
w/o listing "master"
That said, your question made me realize i overlooked something that should
definitely be part of S5: We need to keep an eye out for issues that were
backported to branch_6x *after* branch_6_0 was created, and were *not*
backported to branch-6_0 -- in which case fixVersion=6.0 needs _removed_ in S5.
In my original brainstorming of this plan, i was going to do this audit twice
(once *before* merging the versions when "master" could be removed from issues
w/only "master" commits, and once after to add 6.0 in the paranoia case
described above) making this extra check unneccessary. But this order seemed
better because it means we only have to audit the list one time, w/o any time
pressure and w/o the list continually growing as people resolve more 6.1 issues.
(S6 should also catch these issues, but i wanted redundency since it's possible
people made issue# typos in the git commit messages)
I've updated the steps in the issue description accordingly.
> Cleanup jira's concept of 'master' and '6.0'
> --------------------------------------------
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted &
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> ----
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with
> 'fixVersion=master AND fixVersion=6.1'
> **
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query
> done, and will map the list back to this issue (ex
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all
> issues affected (by merging jira's concepts of 'master' and '6.0') after the
> fact if need be.
> ** Queries to use for bulk edits:
> *** master:
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0:
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when
> the issue should get fixVersion="master (7.0)" *added* to it or
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with
> fixVersion="master (7.0)" on the handful of issues where appropriate in case
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if
> this is a deprecation type situation (involving diff commits in both 6.0 and
> master) in which case fixVersion="master (7.0)" should be _added_ in addition
> to fixVersion=6.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
