[
https://issues.apache.org/jira/browse/HBASE-14025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14614032#comment-14614032
]
Sean Busbey commented on HBASE-14025:
-------------------------------------
(opinion): JIRA is the source of truth for what is fixed in a given version.
The CHANGES.txt file in a release is meant as a convenience for downstream
folks who might not have access to JIRA. A primary benefit of providing this
convenience is making sure the RM does a pass at validating the fix versions
set in JIRA.
# Clean up JIRA for your release
## get the release notes from JIRA in text format and save it (i.e. as
CHANGES_1.2.0_jira.txt)
### i.e. project home -> versions -> 1.2.0 -> Release Notes -> Configure
Release Notes -> format: text -> Create (leads to [these text release notes for
1.2.0|https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12332062&styleName=Text&projectId=12310753]
### the text box at the bottom will have the contents to copy
### filter the file to be just a list of JIRA IDs {code}
# on OS X, just use pbpaste as the first stage of this pipeline instead of
saving to a temp file
$ cat CHANGES_1.2.0_raw.txt | grep -o -E "\[HBASE-[0-9]*\]" | grep -o -E
"HBASE-[0-9]*" | sort -u > CHANGES_1.2.0_jira.txt
{code}
## get the set of JIRAs that are marked in git
### find the commit where your release line branched off from the previous
release. {code}
$ git merge-base 1.1.0 branch-1.2
8166142b2e815fc6ab30c14a5a546cd242bf3b4c
{code}
### get the set of all jiras committed between that branch point and the
previous release. {code}
$ git log --oneline 8166142...1.1.0 | grep -o -E " HBASE-[0-9]* " | awk
'{$1=$1;print}' | sort -u > in_1.1.0.txt
{code}
### get the set of all jiras committed between that branch point and the
current release.{code}
$ git log --oneline 8166142...branch-1.2 | grep -o -E " HBASE-[0-9]* " | awk
'{$1=$1;print}' | sort -u > in_1.2.0.txt
{code}
### check the set of jiras that appear in the previous release after the branch
but not in the current release.{code}
$ comm -2 -3 in_1.1.0.txt in_1.2.0.txt
{code}
###* these can be release specific changes (i.e. disabling DLR in the 1.1.0
release)
###* they can be changes that were reverted during the prior release's RC
process that have not been reapplied
###* they can be changes that were mistakenly only applied in the branch for
the previous release and need to be cherry picked
### find the jiras for the current release that were not applied to the
previous release after branching. this should be all the jiras that are in git
for the current release.{code}
$ comm -1 -3 in_1.1.0.txt in_1.2.0.txt > CHANGES_1.2.0_git.txt
{code}
## go through JIRAs that appear in the JIRA tracker but not in git {code}
$ comm -1 -3 CHANGES_1.2.0_git.txt CHANGES_1.2.0_jira.txt
{code}
##* the above process can give you false positive here, e.g. if a commit was in
the prior release but then reverted and reapplied in your release—be sure to
check the git history
##* sometimes these are issue that didn't get properly cleaned up when things
made it into the previous minor/major release during the RC process
##* sometimes they're task or umbrella jiras that don't have a representation
in git
##* sometimes they're documentation jiras that shouldn't have been marked for
the release (doc tickets always are resolved against the major version that was
in the _master_ git branch at the time)
##* sometimes they're improperly closed tickets (e.g. invalid, duplicate, and
wontfix tickets should not have a fix version)
##* sometimes they were improperly labeled on commit and weren't reverted and
reapplied with the correct commit message.
##* occasionally they're changes that should be in your branch but were missed.
in this case reopen the ticket and cherry-pick to your branch
## go through JIRAs that appear in git but not in JIRA {code}
$ comm -2 -3 CHANGES_1.2.0_git.txt CHANGES_1.2.0_jira.txt
{code}
##* sometimes these were improperly labeled on commit. ideally they will have
been reverted and reapplied with the correct commit message.
##* sometimes they weren't marked correctly in jira because they were pushed
out of the previous minor/major release during the RC process.
# remove entries in CHANGES.txt unrelated to your current release
#* for a PATCH release, you should be starting from a file that only contains
related changes
#* for a MINOR release, you should reset the file so that you will only have
changes for prior minor releases in the same major release (e.g. for the 1.2.0
release CHANGES.txt will start by copying the notes from 1.0.0 and 1.1.0)
#* for a MAJOR release, you should reset the file so that you will only have
changes for prior major releases (e.g. for the 2.0.0 release CHANGES.txt will
start by copying the notes from 1.0.0)
# generate a post-clean-up set of text release notes from JIRA and add it to
the top of the CHANGES.txt file with the current date.
> Update CHANGES.txt for 1.2
> --------------------------
>
> Key: HBASE-14025
> URL: https://issues.apache.org/jira/browse/HBASE-14025
> Project: HBase
> Issue Type: Sub-task
> Components: documentation
> Affects Versions: 1.2.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Fix For: 1.2.0
>
>
> Since it's more effort than I expected, making a ticket to track actually
> updating CHANGES.txt so that new RMs have an idea what to expect.
> Maybe will make doc changes if there's enough here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
