On Jul 8, 2015 2:13 AM, Tsuyoshi Ozawa oz...@apache.org wrote:
+1, thanks Allen and Andrew for taking lots effort!
Is there any possibility that, we can restrict someone from editing the
issue in jira once its marked as closed after release?
Vinay's comment looks considerable for us to
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa oz...@apache.org wrote:
+1, thanks Allen and Andrew for taking lots effort!
Is there any possibility that, we can restrict someone from editing the
issue in jira once its marked as closed after release?
Hello all,
As I am no longer associated with Hadoop,I request you to kindly remove me
from the thread.
Thanks
On 2 Apr 2015 06:40, Allen Wittenauer a...@altiscale.com wrote:
Hello everyone!
(to: and reply-to: set to common-dev, cc: the rest of ‘em, to
concentrate the discussion)
+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
+1, thanks Allen and Andrew for taking lots effort!
Is there any possibility that, we can restrict someone from editing the
issue in jira once its marked as closed after release?
Vinay's comment looks considerable for us to me. What do you think?
- Tsuyoshi
On Wed, Jul 8, 2015 at 3:57 PM,
+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
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
+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
+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,
+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 wrote:
Hi all,
I want to revive the discussion on this thread, since the overhead of
CHANGES.txt came up again in
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
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
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.
+Vinod
On Apr 2, 2015, at 10:12 AM, Allen Wittenauer
On Apr 2, 2015, at 11:36 AM, Mai Haohui ricet...@gmail.com wrote:
Hi Allen,
Thanks for driving this. Just some quick questions:
Removing changes.txt, relnotes.py, etc from branch-2 would be an
incompatible change. Pushing aside the questions of that document’s
quality (hint:
On Apr 2, 2015, at 9:51 AM, Karthik Kambatla ka...@cloudera.com wrote:
a) remove CHANGES.TXT from trunk
Removing this from trunk makes it particularly hard to cherry-pick changes
from trunk to branch-2. I would gate this on the removal of CHANGES.txt on
branch-2 as well, at least until
Hi Allen,
Thanks for driving this. Just some quick questions:
Removing changes.txt, relnotes.py, etc from branch-2 would be an
incompatible change. Pushing aside the questions of that document’s quality
(hint: lots of outright lying and missing several hundred jiras), it's
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
Hello everyone!
(to: and reply-to: set to common-dev, cc: the rest of ‘em, to
concentrate the discussion)
HADOOP-11731 has just been committed to *trunk*. This change does two
things:
a) Removes dev-support/relnotes.py
b) Adds dev-support/releasedocmaker.py
18 matches
Mail list logo
