Hi Anu,
Again apologies in advance for phone typing, flight delays means I'm still
writing this from an airport :(
In Owen's proposal, it says to delete the module from the release branch.
We need to do this since the source tarball is our official Apache release
artifact, the rest are convenience binaries. So the Maven profile is
insufficient for this.
Best,
Andrew
On Mar 21, 2018 2:33 PM, "Anu Engineer" <aengin...@hortonworks.com> wrote:
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
>
>
>
>
