lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'
Date Thu, 05 May 2016 19:26:12 GMT


Hoss Man commented on LUCENE-7271:

I haven't seen any objections to this plan, and i haven't been able to think of any flaws
or possible improvements.

My plan is to start working through these steps tomorrow (Friday) morning ~9AM my time, (~1600

Steps S1-S4 will need to be done carefully and in a single block to reduce the risk of missing
issues edited between steps (but obviously skimming mail for issues people modify during that
window can be done after the fact).

Steps S5 & S6 should be done ASAP after that to reduce confusion as people read/edit jiras,
but don't need to be rushed (ie: i'll go to lunch at some point) and can be divided up among
multiple people if other folks want to volunteer.

I'll track progress with comments here, and attach the reports i generate from S1, S5, and
S6 to this issue as i go.

I'll be on freenodes #lucene IRC channel the whole time if people have concerns or want to
coordinate on helping out with S5 & S6.

> Cleanup jira's concept of 'master' and '6.0'
> --------------------------------------------
>                 Key: LUCENE-7271
>                 URL:
>             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...
> 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'
> **
> *** 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:
> *** 6.0:
> * 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
> ** 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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message