lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'
Date Thu, 05 May 2016 21:43:13 GMT

     [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message