hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wangda Tan <wheele...@gmail.com>
Subject Re: [DISCUSS] Branches and versions for Hadoop 3
Date Tue, 29 Aug 2017 18:45:51 GMT
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