Yaayy!! +1
On Tue, Mar 8, 2016 at 10:59 AM, Colin P. McCabe wrote:
> +1
>
> Thanks, Andrew. This will avoid so many spurious conflicts when
> cherry-picking changes, and so much wasted time on commit.
>
> best,
> Colin
>
> On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang
> wrote:
> > Hi all,
> >
>
+1
Thanks, Andrew. This will avoid so many spurious conflicts when
cherry-picking changes, and so much wasted time on commit.
best,
Colin
On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang wrote:
> Hi all,
>
> With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
> and release note
Great change! Saving ~1min for each commit. Thanks Andrew and Allen.
On Thu, Mar 3, 2016 at 9:32 PM Yongjun Zhang wrote:
> That's nice, thanks Andrew and Allen.
>
> --Yongjun
>
> On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang
> wrote:
>
> > Hi all,
> >
> > With the inclusion of HADOOP-12651 going
That's nice, thanks Andrew and Allen.
--Yongjun
On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang
wrote:
> Hi all,
>
> With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
> and release notes are now generated by Yetus. I've gone ahead and deleted
> the manually updated CHANGES.tx
On Mon, Sep 14, 2015 at 1:09 PM, Andrew Wang wrote:
> I put some time into this a little while back, doing releasedocmaker
> backports from the Yetus branch. IIRC from Allen, we still need to get lint
> mode working before it's good to go. Probably a good bit of JIRA cleanup
> will be required to
I don't understand your negative tone. What point specifically did I
and other people in the conversation miss?
Colin
On Tue, Sep 22, 2015 at 6:21 PM, Allen Wittenauer wrote:
>
> I don’t whether your ability to completely miss my point every time we
> communicate with each other, regardless of
I don’t whether your ability to completely miss my point every time we
communicate with each other, regardless of the issue, is intentional or just a
special talent.
On Sep 22, 2015, at 8:52 AM, Colin P. McCabe wrote:
> I think it's extremely unrealistic to expect Hadoop to ever follow a
> br
I think it's extremely unrealistic to expect Hadoop to ever follow a
branchless development model. In fact, the recent trend has been in
the opposite direction-- prominent members of the community have
pointed out that we don't have enough long-running, well-tested and
well-supported branches. Pr
On Sep 14, 2015, at 5:15 PM, Colin P. McCabe wrote:
> Let's stay focused on the title of the thread-- CHANGES.txt-- and
> discuss issues surrounding releasing trunk in a separate thread.
It directly addresses the thread: if one isn’t cherry picking patches
because there aren’t multip
Let's stay focused on the title of the thread-- CHANGES.txt-- and
discuss issues surrounding releasing trunk in a separate thread.
Colin
On Mon, Sep 14, 2015 at 3:59 PM, Allen Wittenauer wrote:
>
> Given that we haven’t had a single minor release in the “stable” era
> of branch-2 that d
Given that we haven’t had a single minor release in the “stable” era of
branch-2 that didn’t break compatibility, we should just declare defeat and
make regular releases from trunk as the next 2.x. Then the whole “back port”
thing becomes moot. We’ve already trained users that they ne
On Sat, Sep 12, 2015 at 11:28 AM, Haohui Mai wrote:
> CHANGES.txt is always a pain. *sigh*
>
> It seems that relying on human efforts to maintain the CHANGES.txt is
> error-prone and not sustainable. It is always a pain to fix them.
>
> I think aw has some scripts for option 2.
>
> I would like to
I put some time into this a little while back, doing releasedocmaker
backports from the Yetus branch. IIRC from Allen, we still need to get lint
mode working before it's good to go. Probably a good bit of JIRA cleanup
will be required to get a clean lint run.
On Sun, Sep 13, 2015 at 4:38 AM, Steve
> On 12 Sep 2015, at 20:26, Allen Wittenauer wrote:
>
>
> On Sep 12, 2015, at 12:25 PM, Allen Wittenauer wrote:
>
>>
>> On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>>
>>>
>>> 2. go to JIRA-generated change logs. Though for that to be reliable, those
>>> fix-version fields have to
On Sep 12, 2015, at 12:25 PM, Allen Wittenauer wrote:
>
> On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>
>>
>> 2. go to JIRA-generated change logs. Though for that to be reliable, those
>> fix-version fields have to be 100% accurate too.
P.S.,
https://github.com/aw-altiscale/eco-r
On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>
> 1. audit trunk/CHANGES.TXT against branch-2/CHANGES.TXT; anything in
> branch-2's (i.e. to come in 2.8) is placed into trunk at that location; the
> "new in trunk" runk's version removed
>
> 2. go to JIRA-generated change logs. Though
CHANGES.txt is always a pain. *sigh*
It seems that relying on human efforts to maintain the CHANGES.txt is
error-prone and not sustainable. It is always a pain to fix them.
I think aw has some scripts for option 2.
I would like to propose option 3 which might be more robust: (1) do a
git log on
Thanks for taking care of this Sid.
Agree that using jira fix versions would be easier as a way to generate the
changes. It would require some proper handling by the committer. For
example, if something is committed to trunk(3.0.0) and branch-2(2.0.5) it
would have fixedVersion 2.0.5, if later it
I went ahead and committed a couple of changes to trunk and branch-2 to fix
the MR CHANGES.txt mess. Alexandro, I believe there's a couple of jiras
where you were waiting for CHANGES.txt fixes before merging to branch-2.
Not sure about past discussions, but can we re-visit removing CHANGES.txt
in
I started looking at this yesterday, MAPREDUCE CHANGES.txt is completely
broken. I'll try to fix it and then send out a note once I am done.
Thanks,
+Vinod
On Apr 1, 2013, at 11:46 PM, Vinod Kumar Vavilapalli wrote:
>
> I've been looking at YARN and it seems to be fine. I presume common and hd
I've been looking at YARN and it seems to be fine. I presume common and hdfs
too.
MR clearly has issues. Have to manually fix it. Will do something tomorrow
first thing.
Thanks,
+Vinod Kumar Vavilapalli
On Apr 1, 2013, at 3:53 PM, Alejandro Abdelnur wrote:
> while trying to commit MAPREDUCE-
21 matches
Mail list logo
