hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Subramaniam V K <subru...@gmail.com>
Subject Re: [DISCUSS] Branches and versions for Hadoop 3
Date Tue, 29 Aug 2017 19:21:55 GMT
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 have:

   1. a significant incompatible change.
   2. a new feature that cannot be turned off without affecting core
   components.

In summary, I feel we should follow a lazy rather than eager approach
towards creating mainline branches.

Thanks,
Subru



On Tue, Aug 29, 2017 at 11:45 AM, Wangda Tan <wheeleast@gmail.com> wrote:

> 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 <andrew.wang@cloudera.com>
> 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 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 <wheeleast@gmail.com>
> wrote:
> >
> >> 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) are
> >> targeted to merge to 3.0-GA but not 3.0-beta1, which branch we should
> >> commit to, and when we can commit? Also, similar to 3.0.0-alpha1 to 4,
> you
> >> will cut branch-3.0.0-beta1, correct?
> >>
> >> Thanks,
> >> Wangda
> >>
> >>
> >> On Tue, Aug 29, 2017 at 11:05 AM, Andrew Wang <andrew.wang@cloudera.com
> >
> >> wrote:
> >>
> >>> 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 <vrushalic2016@gmail.com>
> >>> wrote:
> >>>
> >>>> 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: your resource profile vote ends tomorrow, could we please
> >>>> coordinate our merges?
> >>>>
> >>>> thanks
> >>>> Vrushali
> >>>>
> >>>>
> >>>> On Mon, Aug 28, 2017 at 10:45 PM, Rohith Sharma K S <
> >>>> rohithsharmaks@apache.org> wrote:
> >>>>
> >>>>> On 29 August 2017 at 06:24, Andrew Wang <andrew.wang@cloudera.com>
> >>>>> 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-SNAPSHOT) and
> >>>>> branch-3.0(3.0.0-beta1-SNAPSHOT) ? If so, would you be able to wait
> >>>>> for
> >>>>> couple of more days before creating branch-3.0 so that TSv2 branch
> >>>>> merge
> >>>>> would be done directly to trunk?
> >>>>>
> >>>>>
> >>>>>
> >>>>> >
> >>>>> > 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 in general. In the past, I've seen some patches
> >>>>> committed
> >>>>> > to trunk-only as a way of passing responsibility to a future
user
> or
> >>>>> > reviewer. That doesn't help anyone; patches should be committed
> with
> >>>>> the
> >>>>> > intent of running them in production.
> >>>>> >
> >>>>> > I'd also like to repeat the above thanks to the many, many
> >>>>> contributors
> >>>>> > who've helped with release improvements. Allen's work on
> >>>>> create-release and
> >>>>> > automated changes and release notes were essential, as was
Xiao's
> >>>>> work on
> >>>>> > LICENSE and NOTICE files. I'm also looking forward to Marton's
site
> >>>>> > improvements, which addresses one of the remaining sore spots
in
> the
> >>>>> > release process.
> >>>>> >
> >>>>> > Things have gotten smoother with each alpha we've done over
the
> last
> >>>>> year,
> >>>>> > and it's a testament to everyone's work that we have a good
> >>>>> probability of
> >>>>> > shipping beta and GA later this year.
> >>>>> >
> >>>>> > Cheers,
> >>>>> > Andrew
> >>>>> >
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message