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" wrote:
> Hello everyone!
>
> (to: and reply-to: set to common-dev, cc: the rest of ‘em, to
> concentrate the discussion)
>
> HADO
I think it defeats the purpose ofu
On Jul 8, 2015, at 12:13 AM, Tsuyoshi Ozawa 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 comm
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" 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 me. Wh
+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.
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 wrote:
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vi
+1
Thanks Allen and Andrew for your efforts on this.
Thanks
Devaraj
On Fri, Jul 3, 2015 at 11:29 AM, Varun Vasudev wrote:
> +1
>
> Many thanks to Allen and Andrew for driving this.
>
> -Varun
>
>
>
> On 7/3/15, 10:25 AM, "Vinayakumar B" wrote:
>
> >+1 for the auto generation.
> >
> >bq. Besid
+1
Many thanks to Allen and Andrew for driving this.
-Varun
On 7/3/15, 10:25 AM, "Vinayakumar B" 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 restric
+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,
Huge +1
On Thursday, July 2, 2015, Chris Nauroth 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" >
> wrote:
>
> >Hi all,
> >
> >I want to revive the discussion o
+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" 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 bac
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 everywh
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 chan
On Apr 2, 2015, at 12:40 PM, Vinod Kumar Vavilapalli
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
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
mailto:a..
On Apr 2, 2015, at 11:36 AM, Mai Haohui 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: lots of
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
>>
On Apr 2, 2015, at 9:51 AM, Karthik Kambatla 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 we have s
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
releasedoc
18 matches
Mail list logo
