Generating change log from JIRA is a good idea. It bases on an assumption that
each JIRA has an accurate summary (a.k.a. JIRA title) to reflect the committed
change. Unfortunately, the assumption is invalid for many cases since we never
enforce that the JIRA summary must be the same as the change log. We may
compare the current CHANGES.txt with the generated change log. I beg the diff
is long.
Besides, after a release R1 is out, someone may (accidentally or intentionally)
modify the JIRA summary. Then, the entry for the same item in a later release
R2 could be different from the one in R1.
I agree that manually editing CHANGES.txt is not a perfect solution. However,
it works well in the past for many releases. I suggest we keep the current dev
workflow. Try using the new script provided by HADOOP-11731 to generate the
next release. If everything works well, we shell remove CHANGES.txt and revise
the dev workflow. What do you think?
Regards,Tsz-Wo
On Thursday, April 2, 2015 12:57 PM, Allen Wittenauer <a...@altiscale.com>
wrote:
On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <vino...@hortonworks.com>
wrote:
>
> We'd then doing two commits for every patch. Let's simply not remove
> CHANGES.txt from trunk, keep the existing dev workflow, but doc the release
> process to remove CHANGES.txt in trunk at the time of a release going out of
> trunk.
Might as well copy branch-2’s changes.txt into trunk then. (or 2.7’s. Last I
looked, people updated branch-2 and not 2.7’s or vice versa for some patches
that went into both branches.) So that folks who are committing to both
branches and want to cherry pick all changes can.
I mean, trunk’s is very very very wrong. Right now. Today. Borderline useless.
See HADOOP-11718 (which I will now close out as won’t fix)… and that jira is
only what is miscategorized, not what is missing.
