Hi Andrew,
Thanks for your comment.
>” Having to delete it each time means more work for mainline RMs and more room
>for error.”
The current change that we have done has a maven profile called “–Phdsl,"
without this flag it
will not be compiled and will not be included in source or binary packages.
Therefore, explicit delete is not needed.
In other words, RM does not need to do any extra work. There is no change to
the default Hadoop Release process.
Thanks
Anu
On 3/21/18, 2:18 PM, "Andrew Wang" <andrew.w...@cloudera.com> wrote:
Hi folks,
Sorry for not replying earlier, I've been on vacation for the last week and
am writing this on my phone from the airport now. Please excuse me if this
is terser than my normal emails.
I really like the direction of Owen's proposal, thanks Owen for driving
this toward a conclusion acceptable to everyone involved.
My main question about this proposal: could we release from the branch
rather than merging and deleting it for every release? Since we don't have
a Hadoop 4 branch and branch minors off of trunk, every branch is sort of a
release branch. Having to delete it each time means more work for mainline
RMs and more room for error. Since compilation is off by default and it
uses a separate precommit (which I read as ways of isolating HDSL from the
rest of Hadoop development), releasing from the branch feels like another
form of isolation along those same lines. This is also less additional
infra work since we have the branch and branch precommit humming along.
I think establishing the HDSL subproject achieves the desired goal of
encouraging HDSL development and keeping it close to the HDFS community.
Releasing from a branch does not affect the legitimacy of HDSL as a
subproject and maximizes development and release speed for both mainline
3.x releases and HDSL releases.
Sorry again for not chiming in earlier before this VOTE was started. If
this change is acceptable to everyone, hopefully we can make it without
starting a new vote. I'd be happy to vote +1.
Best,
Andrew
On Mar 21, 2018 1:17 PM, "Ajay Kumar" <ajay.ku...@hortonworks.com> wrote:
> +1 (non-binding)
>
> On 3/20/18, 9:43 PM, "Jitendra Pandey" <jiten...@hortonworks.com> wrote:
>
> +1 (binding)
>
> On 3/20/18, 8:39 PM, "Weiwei Yang" <cheersy...@hotmail.com> wrote:
>
> +1 (non-binding)
> I really like this proposal and thanks for all the discussions.
>
> --
> Weiwei
>
> On 21 Mar 2018, 8:39 AM +0800, Arpit Agarwal <
> aagar...@hortonworks.com>, wrote:
> +1 (binding)
>
> Arpit
>
> On 3/20/18, 11:21 AM, "Owen O'Malley" <owen.omal...@gmail.com>
> wrote:
>
> All,
>
> Following our discussions on the previous thread (Merging branch
> HDFS-7240
> to trunk), I'd like to propose the following:
>
> * HDSL become a subproject of Hadoop.
> * HDSL will release separately from Hadoop. Hadoop releases will
> not
> contain HDSL and vice versa.
> * HDSL will get its own jira instance so that the release tags
stay
> separate.
> * On trunk (as opposed to release branches) HDSL will be a
> separate module
> in Hadoop's source tree. This will enable the HDSL to work on
> their trunk
> and the Hadoop trunk without making releases for every change.
> * Hadoop's trunk will only build HDSL if a non-default profile is
> enabled.
> * When Hadoop creates a release branch, the RM will delete the
> HDSL module
> from the branch.
> * HDSL will have their own Yetus checks and won't cause failures
> in the
> Hadoop patch check.
>
> I think this accomplishes most of the goals of encouraging HDSL
> development
> while minimizing the potential for disruption of HDFS development.
>
> The vote will run the standard 7 days and requires a lazy 2/3
> vote. PMC
> votes are binding, but everyone is encouraged to vote.
>
> +1 (binding)
>
> .. Owen
>
>
> �����������������������������������������������������������
> ����������ХF�V�7V'67&�&R�R���â�Fg2�FWb�V�7V'67&�&T�F���6�R�
> �&pФf�"FF�F����6����G2�R���â�Fg2�FWbֆV��F���6�R��&pР
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>
>
