+1, thanks Allen and Andrew.
Regards,
Akira
On 7/3/15 22:31, Devaraj K wrote:
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev <vvasu...@apache.org> wrote:
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" <vinayakum...@apache.org> wrote:
+1 for the auto generation.
bq. Besides, after a release R1 is out, someone may (accidentally or
intentionally) modify the JIRA summary.
Is there any possibility that, we can restrict someone from editing the
issue in jira once its marked as "closed" after release?
Regards,
Vinay
On Fri, Jul 3, 2015 at 8:32 AM, Karthik Kambatla <ka...@cloudera.com>
wrote:
Huge +1
On Thursday, July 2, 2015, Chris Nauroth <cnaur...@hortonworks.com>
wrote:
+1
Thank you to Allen for the script, and thank you to Andrew for
volunteering to drive the conversion.
--Chris Nauroth
On 7/2/15, 2:01 PM, "Andrew Wang" <andrew.w...@cloudera.com
<javascript:;>>
wrote:
Hi all,
I want to revive the discussion on this thread, since the overhead of
CHANGES.txt came up again in the context of backporting fixes for
maintenance releases.
Allen's automatic generation script (HADOOP-11731) went into trunk
but
not
branch-2, so we're still maintaining CHANGES.txt everywhere. What do
people
think about backporting this to branch-2 and then removing
CHANGES.txt
from
trunk/branch-2 (HADOOP-11792)? Based on discussion on this thread
and in
HADOOP-11731, we seem to agree that CHANGES.txt is an unreliable
source
of
information, and JIRA is at least as reliable and probably much more
so.
Thus I don't see any downsides to backporting it.
Would like to hear everyone's thoughts on this, I'm willing to drive
the
effort.
Thanks,
Andrew
On Thu, Apr 2, 2015 at 2:00 PM, Tsz Wo Sze
<szets...@yahoo.com.invalid>
wrote:
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 <javascript:;>> wrote:
On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com <javascript:;>> 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.
--
Mobile
