Hi folks,
We've landed two of our beta1 features, S3Guard and TSv2, into trunk. Jian
just sent out the vote for our remaining beta1 feature, YARN native
services, but I think it's time to branch to unblock the resource profiles
merge to 3.1.
I'll cut just branch-3.0 for now, since we don't have a
> On Aug 28, 2017, at 9:58 AM, Allen Wittenauer
> wrote:
> The automation only goes so far. At least while investigating Yetus
> bugs, I've seen more than enough blatant and purposeful ignored errors and
> warnings that I'm not convinced it will be effective. ("That javadoc compile
> f
Hi Andrew,
We have completed the merge of TSv2 to trunk.
You can now go ahead with the branching.
Regards,
Varun Saxena.
On Tue, Aug 29, 2017 at 11:35 PM, Andrew Wang
wrote:
> Sure. Ping me when the TSv2 goes in, and I can take care of branching.
>
> We're still waiting on the native services
Hi Subru,
Basically we're amending the proposal from the original email in the chain
to also immediately create the branch-3.0.0-beta1 release branch. As
described in my 2017-08-25 wiki update, we're gating the merge of these two
features to branch-3.0 on additional testing, but this keeps 3.0.0
Andrew,
First up thanks for tirelessly pushing on 3.0 release.
I am confused about your comment on creating 2 branches as my understanding
of Jason's (and Vinod's) comments are that we defer creating branch-3?
IMHO, we should consider creating branch-3 (necessary but not sufficient)
only when we
Gotcha, make sense, so I will hold commit until you cut the two branches
and TSv2 get committed.
Thanks,
Wangda
On Tue, Aug 29, 2017 at 11:25 AM, Andrew Wang
wrote:
> Hi Wangda,
>
> I'll cut two branches: branch-3.0 (3.0.0-SNAPSHOT) and branch-3.0.0-beta1
> (3.0.0-beta1-SNAPSHOT). This way we c
Hi Wangda,
I'll cut two branches: branch-3.0 (3.0.0-SNAPSHOT) and branch-3.0.0-beta1
(3.0.0-beta1-SNAPSHOT). This way we can merge GA features to branch-3.0 but
not branch-3.0.0-beta1.
Best,
Andrew
On Tue, Aug 29, 2017 at 11:18 AM, Wangda Tan wrote:
> Vrushali,
>
> Sure we can wait TSv2 merged
Vrushali,
Sure we can wait TSv2 merged before merge resource profile branch.
Andrew,
My understanding is you're going to cut branch-3.0 for 3.0-beta1, and the
same branch (branch-3.0) will be used for 3.0-GA as well. So my question
is, there're several features (TSv2, resource profile, YARN-5734
Sure. Ping me when the TSv2 goes in, and I can take care of branching.
We're still waiting on the native services and S3Guard merges, but I don't
want to hold branching to the last minute.
On Tue, Aug 29, 2017 at 10:51 AM, Vrushali C
wrote:
> Hi Andrew,
> As Rohith mentioned, if you are good wi
Hi Andrew,
As Rohith mentioned, if you are good with it, from the TSv2 side, we are
ready to go for merge tonight itself (Pacific time) right after the voting
period ends. Varun Saxena has been diligently rebasing up until now so most
likely our merge should be reasonably straightforward.
@Wangda
On 29 August 2017 at 06:24, Andrew Wang wrote:
> So far I've seen no -1's to the branching proposal, so I plan to execute
> this tomorrow unless there's further feedback.
>
For on going branch merge threads i.e TSv2, voting will be closing
tomorrow. Does it end up in merging into trunk(3.1.0-SNAP
So far I've seen no -1's to the branching proposal, so I plan to execute
this tomorrow unless there's further feedback.
Regarding the above discussion, I think Jason and I have essentially the
same opinion.
I hope that keeping trunk a release branch means a higher bar for merges
and code review i
On Mon, Aug 28, 2017, at 14:22, Allen Wittenauer wrote:
>
> > On Aug 28, 2017, at 12:41 PM, Jason Lowe wrote:
> >
> > I think this gets back to the "if it's worth committing" part.
>
> This brings us back to my original question:
>
> "Doesn't this place an undue burden on the contr
> On Aug 28, 2017, at 12:41 PM, Jason Lowe wrote:
>
> I think this gets back to the "if it's worth committing" part.
This brings us back to my original question:
"Doesn't this place an undue burden on the contributor with the first
incompatible patch to prove worthiness? What
+1 to Andrew’s proposal for 3.x releases.
We had fairly elaborate threads on this branching & compatibility topic before.
One of them’s here: [1]
+1 to what Jason said.
(a) Incompatible changes are not to be treated lightly. We need to stop
breaking stuff and ‘just dump it on trunk'.
(b) Maj
Allen Wittenauer wrote:
> > On Aug 25, 2017, at 1:23 PM, Jason Lowe wrote:
> >
> > Allen Wittenauer wrote:
> >
> > > Doesn't this place an undue burden on the contributor with the first
> incompatible patch to prove worthiness? What happens if it is decided that
> it's not good enough?
> >
> >
> On Aug 25, 2017, at 1:23 PM, Jason Lowe wrote:
>
> Allen Wittenauer wrote:
>
> > Doesn't this place an undue burden on the contributor with the first
> > incompatible patch to prove worthiness? What happens if it is decided that
> > it's not good enough?
>
> It is a burden for that first
Allen Wittenauer wrote:
> Doesn't this place an undue burden on the contributor with the first
> incompatible patch to prove worthiness? What happens if it is decided that
> it's not good enough?
It is a burden for that first, "this can't go anywhere else but 4.x"
change, but arguably that sho
Plan looks good to me.
+1
Regards,
Uma
On 8/25/17, 10:36 AM, "Andrew Wang" wrote:
>Hi folks,
>
>With 3.0.0-beta1 fast approaching, I wanted to go over the proposed
>branching strategy.
>
>In the early 2.x days, moving trunk immediately to 3.0.0 was a mistake.
>branch-2 and trunk were virtually
Hi Andrew,
Thanks for updating the proposal, +1.
- Wangda
On Fri, Aug 25, 2017 at 12:16 PM, Allen Wittenauer wrote:
>
> > On Aug 25, 2017, at 10:36 AM, Andrew Wang
> wrote:
>
> > Until we need to make incompatible changes, there's no need for
> > a Hadoop 4.0 version.
>
> Some questions:
>
>
> On Aug 25, 2017, at 10:36 AM, Andrew Wang wrote:
> Until we need to make incompatible changes, there's no need for
> a Hadoop 4.0 version.
Some questions:
Doesn't this place an undue burden on the contributor with the first
incompatible patch to prove worthiness? What happens if it
e-...@hadoop.apache.org" ; "
> hdfs-dev@hadoop.apache.org" ; "
> yarn-...@hadoop.apache.org"
> Sent: Friday, August 25, 2017 12:36 PM
> Subject: [DISCUSS] Branches and versions for Hadoop 3
>
> Hi folks,
>
> With 3.0.0-beta1 fast approaching, I want
+1 for this branching proposal.-Eric
From: Andrew Wang
To: "common-...@hadoop.apache.org" ;
"mapreduce-...@hadoop.apache.org" ;
"hdfs-dev@hadoop.apache.org" ;
"yarn-...@hadoop.apache.org"
Sent: Friday, August 25, 2017 12:36 PM
Subject: [DIS
Hi folks,
With 3.0.0-beta1 fast approaching, I wanted to go over the proposed
branching strategy.
In the early 2.x days, moving trunk immediately to 3.0.0 was a mistake.
branch-2 and trunk were virtually identical, and increased backport
complexity. Until we need to make incompatible changes, the
24 matches
Mail list logo
