Should we even have {{6.x}} and {{5.x}} versions at all?

No. We have too many people with JIRA admin it seems.

- Mark

On Fri, May 6, 2016 at 10:14 AM Steve Rowe (JIRA) <[email protected]> wrote:

>
>     [
> https://issues.apache.org/jira/browse/LUCENE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274079#comment-15274079
> ]
>
> Steve Rowe commented on LUCENE-7271:
> ------------------------------------
>
> Looking at a different JIRA version problem (see [
> http://markmail.org/message/6ac5szyce3qhoo3l]), I noticed that LUCENE
> (and not SOLR) has version contstants {{6.x}} and {{5.x}} - there are 38
> issues with these as fixVersion-s: [
> https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)
> ].
>
> I think this is a related problem to the master->6.0 issue being dealt
> with here.
>
> Should we even have {{6.x}} and {{5.x}} versions at all?
>
> > 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: [email protected]
> For additional commands, e-mail: [email protected]
>
> --
- Mark
about.me/markrmiller

Reply via email to