Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Vinod Kumar Vavilapalli]

Glad to see consensus on this proposal.

This new subproject will hopefully continue Hadoop's evolution forward (dare I 
say the biggest one since YARN) and also intends to accomplish this with 
minimal project overhead.

+1 binding.

Thanks
+Vinod

> On Mar 20, 2018, at 11:20 AM, Owen O'Malley  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


-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

[RESULT][VOTE] Adopt HDSL as a new Hadoop subproject

[Owen O'Malley]

Ok, with a lot of +1's, one +0, and no -1's the vote passes.

We have a new subproject!

We should resolve the final name and then create a jira instance for it.

Thanks everyone,
   Owen

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Rakesh Radhakrishnan]

+1 for the sub-project idea. Thanks to everyone that contributed!

Regards,
Rakesh

On Tue, Mar 27, 2018 at 4:46 PM, Jack Liu  wrote:

>  +1 (non-binding)
>
>
> On Tue, Mar 27, 2018 at 2:16 AM, Tsuyoshi Ozawa  wrote:
>
> > +1(binding),
> >
> > - Tsuyoshi
> >
> > On Tue, Mar 20, 2018 at 14:21 Owen O'Malley 
> > 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
> > >
> >
>
>
>
> --
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Jack Liu]

 +1 (non-binding)


On Tue, Mar 27, 2018 at 2:16 AM, Tsuyoshi Ozawa  wrote:

> +1(binding),
>
> - Tsuyoshi
>
> On Tue, Mar 20, 2018 at 14:21 Owen O'Malley 
> 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
> >
>



--

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Lei Xu]

+1

Best,

On Mon, Mar 26, 2018 at 10:38 AM, Xiao Chen  wrote:
> +1
>
> Thanks,
> -Xiao
>
> On Sun, Mar 25, 2018 at 9:07 PM, Akira Ajisaka 
> wrote:
>
>> +1
>>
>> Thanks,
>> Akira
>>
>>
>> On 2018/03/24 15:18, Lokesh Jain wrote:
>>
>>> +1 (non-binding)
>>>
>>> Thanks
>>> Lokesh
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
>>> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>>
>>



-- 
Lei (Eddy) Xu
Software Engineer, Cloudera

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Akira Ajisaka]

+1

Thanks,
Akira

On 2018/03/24 15:18, Lokesh Jain wrote:

+1 (non-binding)

Thanks
Lokesh


-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Lokesh Jain]

+1 (non-binding)

Thanks
Lokesh


-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Wei-Chiu Chuang]

+1 (binding)

Happy to see the community converge on a proposal.

On Fri, Mar 23, 2018 at 11:18 AM, Andrew Wang 
wrote:

> +1
>
> If this VOTE is to gather consensus about establishing a new subproject,
> let's definitely proceed with that.
>
> It sounds like we're already discussing changes to the details of how the
> project will be run, and releasing from the branch vs. maven profile is not
> a blocker for me. I raised it since I thought it would reduce the amount of
> additional infra/build work, but it's fine if the preference is to just do
> the work. Sorry if my earlier reply sounded like bikeshedding.
>
> Cheers,
> Andrew
>
> On Fri, Mar 23, 2018 at 10:00 AM, Brahma Reddy Battula 
> wrote:
>
> > +1 ( binding)
> >
> >
> >
> > On Tue, Mar 20, 2018 at 11:50 PM, Owen O'Malley 
> > 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
> > >
> >
> >
> >
> > --
> >
> >
> >
> > --Brahma Reddy Battula
> >
>



-- 
A very happy Hadoop contributor

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Andrew Wang]

+1

If this VOTE is to gather consensus about establishing a new subproject,
let's definitely proceed with that.

It sounds like we're already discussing changes to the details of how the
project will be run, and releasing from the branch vs. maven profile is not
a blocker for me. I raised it since I thought it would reduce the amount of
additional infra/build work, but it's fine if the preference is to just do
the work. Sorry if my earlier reply sounded like bikeshedding.

Cheers,
Andrew

On Fri, Mar 23, 2018 at 10:00 AM, Brahma Reddy Battula 
wrote:

> +1 ( binding)
>
>
>
> On Tue, Mar 20, 2018 at 11:50 PM, Owen O'Malley 
> 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
> >
>
>
>
> --
>
>
>
> --Brahma Reddy Battula
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Brahma Reddy Battula]

+1 ( binding)



On Tue, Mar 20, 2018 at 11:50 PM, Owen O'Malley 
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
>



-- 



--Brahma Reddy Battula

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Mingliang Liu]

+1 (binding)

Thanks!

On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley 
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
>



-- 
Mingliang Liu

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Vinayakumar B]

+1 for the subproject of HDSL

Instead of maintaining directly as part of main repo itself, may be we can
explore 'git submodules'

-Vinay


On 23 Mar 2018 11:47 am, "Takanobu Asanuma"  wrote:

+1 (non-binding).

Thanks,
-Takanobu Asanuma


> 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

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Takanobu Asanuma]

+1 (non-binding).

Thanks,
-Takanobu Asanuma


> 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

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Nandakumar Vadivelu]

+1 (non-binding)

On 3/23/18, 8:23 AM, "dujunp...@gmail.com on behalf of 俊平堵" 
 wrote:

I think the proposal here is the right way to get consensus from each part
of community. +1 (binding)
Thanks Owen for driving this.


Thanks,

Junping

2018-03-21 2:20 GMT+08:00 Owen O'Malley :

> 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
>



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[俊平堵]

I think the proposal here is the right way to get consensus from each part
of community. +1 (binding)
Thanks Owen for driving this.


Thanks,

Junping

2018-03-21 2:20 GMT+08:00 Owen O'Malley :

> 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
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Chen Liang]

+1 (non-binding).

Thanks,
Chen


> On Mar 20, 2018, at 11:20 AM, Owen O'Malley  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


-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Suresh Srinivas]

+1 (Binding)

Regards,
Suresh

On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley 
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
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Hanisha Koneru]

+1 (non-binding).

Thanks,
Hanisha




On 3/22/18, 4:06 PM, "Elek, Marton"  wrote:

>
> > 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.
>
>It's a very good point, but actually it could be handled with maven 
>profile and assembly descriptors. I created HDFS-13335 with a patch to 
>address this issue.
>
>I am +1 for the vote (non-binding).
>
>I am very happy with this in-tree approach as I believe that it will 
>help to establish a practice which could be used for other possible 
>features in the future. And this practice could help to get a safer 
>adoption path for upcomming new features as well.
>
>Marton
>
>On 03/22/2018 05:30 PM, Andrew Wang wrote:
>> 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"  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"  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" 
>> wrote:
>> 
>>  > +1 (non-binding)
>>  >
>>  > On 3/20/18, 9:43 PM, "Jitendra Pandey" 
>> wrote:
>>  >
>>  > +1 (binding)
>>  >
>>  > On 3/20/18, 8:39 PM, "Weiwei Yang"  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" 
>>  > 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

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Elek, Marton]

> 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.

It's a very good point, but actually it could be handled with maven 
profile and assembly descriptors. I created HDFS-13335 with a patch to 
address this issue.


I am +1 for the vote (non-binding).

I am very happy with this in-tree approach as I believe that it will 
help to establish a practice which could be used for other possible 
features in the future. And this practice could help to get a safer 
adoption path for upcomming new features as well.


Marton

On 03/22/2018 05:30 PM, Andrew Wang wrote:

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"  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"  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" 
wrote:

 > +1 (non-binding)
 >
 > On 3/20/18, 9:43 PM, "Jitendra Pandey" 
wrote:
 >
 > +1 (binding)
 >
 > On 3/20/18, 8:39 PM, "Weiwei Yang"  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" 
 > 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 

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Anu Engineer]

Hi Lei/Owen,

Based on Daryn’s suggestion, we have made HDSL a loadable module inside data 
node. 
It relies on the current loadable module support that is already present in 
HDFS. 
This module is loaded by Datanodes only when it is configured.

--Anu


On 3/22/18, 11:25 AM, "Owen O'Malley"  wrote:

On Thu, Mar 22, 2018 at 11:09 AM, Lei Xu  wrote:

>
> I have one concrete question about how this HDSL subproject being
> separated: Ozone / HDSL was designed in the current way to re-use the
> existing HDFS code base as much as possible, thus today for this
> container service is in DataNode itself.


Lei,
   I'll let Jitendra and Anu talk to the details of the remaining changes
to HDFS. My understanding is that they are making changes to the patch to
minimize the impact on HDFS. I'm trying to facilitate the proposal for how
to create and manage the subproject.

.. Owen

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Owen O'Malley]

On Thu, Mar 22, 2018 at 11:09 AM, Lei Xu  wrote:

>
> I have one concrete question about how this HDSL subproject being
> separated: Ozone / HDSL was designed in the current way to re-use the
> existing HDFS code base as much as possible, thus today for this
> container service is in DataNode itself.


Lei,
   I'll let Jitendra and Anu talk to the details of the remaining changes
to HDFS. My understanding is that they are making changes to the patch to
minimize the impact on HDFS. I'm trying to facilitate the proposal for how
to create and manage the subproject.

.. Owen

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Lei Xu]

Hi, Owen

Thanks a lot for this proposal, as I believe it has addressed most of
the concerns of the community.

I have one concrete question about how this HDSL subproject being
separated: Ozone / HDSL was designed in the current way to re-use the
existing HDFS code base as much as possible, thus today for this
container service is in DataNode itself.  It is not clear to me after
separate HDSL into a new project, where would be these code? And if it
is still in DataNode somehow (logically?), how to sync changes between
these two projects even the code is not physically co-located.

I would +1 if this concern will be addressed.

Best,


On Thu, Mar 22, 2018 at 10:35 AM, Chris Douglas  wrote:
> On Thu, Mar 22, 2018 at 10:23 AM, Andrew Wang  
> wrote:
>> We want the git hash to match the contents of the tarball and tag, which is
>> beyond what create release does right now. It doesn't do any git stuff.
>
> ...and it can't? Even if this remains a manual step, it's not a
> significant concession.
>
>> If this vote to adopt a new project also includes merging to trunk (it
>> sounds like it?), I feel like we should settle these questions first.
>
> No, this is just measuring consensus so effort arranging the merge is
> well-spent. The merge vote will come later. -C
>
>> Best,
>> Andrew
>>
>> On Mar 22, 2018 9:51 AM, "Chris Douglas"  wrote:
>>
>> +1 (binding)
>>
>> This compromise seems to address most of the concerns raised during
>> the discussion. Thanks for proposing and driving this, Owen.
>>
>> On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang 
>> wrote:
>>> 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.
>>
>> Eliminating manual steps to create a release is desirable, but
>> privileging it above all the development efficiencies gained by
>> merging to the same repo... we don't cut releases that often.
>>
>> Moreover, the steps to remove the module don't need to be manual. Once
>> we work out the steps, would you be willing to update the
>> create-release script? -C
>>
>>
>> On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley 
>> 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
>>
>> -
>> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
>> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>



-- 
Lei (Eddy) Xu
Software Engineer, Cloudera

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Chris Douglas]

On Thu, Mar 22, 2018 at 10:23 AM, Andrew Wang  wrote:
> We want the git hash to match the contents of the tarball and tag, which is
> beyond what create release does right now. It doesn't do any git stuff.

...and it can't? Even if this remains a manual step, it's not a
significant concession.

> If this vote to adopt a new project also includes merging to trunk (it
> sounds like it?), I feel like we should settle these questions first.

No, this is just measuring consensus so effort arranging the merge is
well-spent. The merge vote will come later. -C

> Best,
> Andrew
>
> On Mar 22, 2018 9:51 AM, "Chris Douglas"  wrote:
>
> +1 (binding)
>
> This compromise seems to address most of the concerns raised during
> the discussion. Thanks for proposing and driving this, Owen.
>
> On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang 
> wrote:
>> 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.
>
> Eliminating manual steps to create a release is desirable, but
> privileging it above all the development efficiencies gained by
> merging to the same repo... we don't cut releases that often.
>
> Moreover, the steps to remove the module don't need to be manual. Once
> we work out the steps, would you be willing to update the
> create-release script? -C
>
>
> On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley 
> 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
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Andrew Wang]

We want the git hash to match the contents of the tarball and tag, which is
beyond what create release does right now. It doesn't do any git stuff.

Also sorry if I missed this, but have we gone through all of Owen and
Daryn's earlier comments about merge readiness? Some of Daryn's in
particular relate to making pluggable DN interfaces which sounded like the
main touch point, which would really reduce the overhead of integrating
changes on a branch. The other big one is dependency changes.

If this vote to adopt a new project also includes merging to trunk (it
sounds like it?), I feel like we should settle these questions first.

Best,
Andrew

On Mar 22, 2018 9:51 AM, "Chris Douglas"  wrote:

+1 (binding)

This compromise seems to address most of the concerns raised during
the discussion. Thanks for proposing and driving this, Owen.

On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang 
wrote:
> 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.

Eliminating manual steps to create a release is desirable, but
privileging it above all the development efficiencies gained by
merging to the same repo... we don't cut releases that often.

Moreover, the steps to remove the module don't need to be manual. Once
we work out the steps, would you be willing to update the
create-release script? -C


On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley 
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

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Chris Douglas]

+1 (binding)

This compromise seems to address most of the concerns raised during
the discussion. Thanks for proposing and driving this, Owen.

On Thu, Mar 22, 2018 at 9:30 AM, Andrew Wang  wrote:
> 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.

Eliminating manual steps to create a release is desirable, but
privileging it above all the development efficiencies gained by
merging to the same repo... we don't cut releases that often.

Moreover, the steps to remove the module don't need to be manual. Once
we work out the steps, would you be willing to update the
create-release script? -C


On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malley  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

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Andrew Wang]

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"  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"  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" 
wrote:

> +1 (non-binding)
>
> On 3/20/18, 9:43 PM, "Jitendra Pandey" 
wrote:
>
> +1 (binding)
>
> On 3/20/18, 8:39 PM, "Weiwei Yang"  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" 
> 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���â�Fg2�FWb�V�7V'67&��F���6�R�
> 

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Mukul Kumar Singh]

+1 (non binding)
Thanks,
Mukul

On 22/03/18, 12:31 PM, "Tsz Wo (Nicholas), Sze" 
 wrote:

 +1 (binding)
Tsz-Wo
On Wednesday, March 21, 2018, 10:38:03 PM PDT, Jakob Homan 
 wrote:  
 
 +1 (binding)

On 21 March 2018 at 20:12, Shashikant Banerjee
 wrote:
> +1(non-binding)
>
> On 3/21/18, 10:13 AM, "Jitendra Pandey"  wrote:
>
>+1 (binding)
>
>On 3/20/18, 8:39 PM, "Weiwei Yang"  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 
, wrote:
>+1 (binding)
>
>Arpit
>
>On 3/20/18, 11:21 AM, "Owen O'Malley"  
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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р
>
>
>
>-
>To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
>For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
  

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Tsz Wo (Nicholas), Sze]

 +1 (binding)
Tsz-Wo
On Wednesday, March 21, 2018, 10:38:03 PM PDT, Jakob Homan 
 wrote:  
 
 +1 (binding)

On 21 March 2018 at 20:12, Shashikant Banerjee
 wrote:
> +1(non-binding)
>
> On 3/21/18, 10:13 AM, "Jitendra Pandey"  wrote:
>
>    +1 (binding)
>
>    On 3/20/18, 8:39 PM, "Weiwei Yang"  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 
>, wrote:
>        +1 (binding)
>
>        Arpit
>
>        On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р
>
>
>
>    -
>    To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
>    For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
  

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Jakob Homan]

+1 (binding)

On 21 March 2018 at 20:12, Shashikant Banerjee
 wrote:
> +1(non-binding)
>
> On 3/21/18, 10:13 AM, "Jitendra Pandey"  wrote:
>
> +1 (binding)
>
> On 3/20/18, 8:39 PM, "Weiwei Yang"  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 
> , wrote:
> +1 (binding)
>
> Arpit
>
> On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р
>
>
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>

-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Shashikant Banerjee]

+1(non-binding)

On 3/21/18, 10:13 AM, "Jitendra Pandey"  wrote:

+1 (binding)

On 3/20/18, 8:39 PM, "Weiwei Yang"  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 
, wrote:
+1 (binding)

Arpit

On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Anu Engineer]

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"  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"  wrote:

> +1 (non-binding)
>
> On 3/20/18, 9:43 PM, "Jitendra Pandey"  wrote:
>
> +1 (binding)
>
> On 3/20/18, 8:39 PM, "Weiwei Yang"  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" 
> 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���â�Fg2�FWb�V�7V'67&��F���6�R�
> �Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р
>
>
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Andrew Wang]

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"  wrote:

> +1 (non-binding)
>
> On 3/20/18, 9:43 PM, "Jitendra Pandey"  wrote:
>
> +1 (binding)
>
> On 3/20/18, 8:39 PM, "Weiwei Yang"  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" 
> 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���â�Fg2�FWb�V�7V'67&��F���6�R�
> �Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р
>
>
>
> -
> To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
>
>
>
>

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Ajay Kumar]

+1 (non-binding)

On 3/20/18, 9:43 PM, "Jitendra Pandey"  wrote:

+1 (binding)

On 3/20/18, 8:39 PM, "Weiwei Yang"  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 
, wrote:
+1 (binding)

Arpit

On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Owen O'Malley]

On Tue, Mar 20, 2018 at 8:34 PM, 郑锴(铁杰)  wrote:

> >>* HDSL become a subproject of Hadoop.
> I'm not compfortable with the HDSL name, as Konstantin mentioned. H-DSL
> looks like a DSL language at the first glance.
>

Let's start a separate thread about the name. My general guidance on naming
things is to let the people do the work have the biggest say in the naming,
although it is a community decision. It is easy to invest way more time in
the name than it deserves, given that whichever name we end up with it will
come to mean this sub-project. For example, if you google "hdsl hadoop"
you'll already have the right page as the first result.

.. Owen

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Jitendra Pandey]

+1 (binding)

On 3/20/18, 8:39 PM, "Weiwei Yang"  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 , 
wrote:
+1 (binding)

Arpit

On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Weiwei Yang]

+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 , wrote:
+1 (binding)

Arpit

On 3/20/18, 11:21 AM, "Owen O'Malley"  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���â�Fg2�FWb�V�7V'67&��F���6�R��Фf�"FF�F6G2�R���â�Fg2�FWbֆV��F���6�R��Р

回复：[VOTE] Adopt HDSL as a new Hadoop subproject

[郑锴(铁杰)]

+0. It's good to move forward and evolve Hadoop further. HDSL is a good 
direction, though still in earlier phase yet. Thanks folks for the long term 
efforts.
>>* HDSL become a subproject of Hadoop.I'm not compfortable with the HDSL name, 
>>as Konstantin mentioned. H-DSL looks like a DSL language at the first glance.
>>* HDSL will get its own jira instance so that the release tags stay 
>>separate.This is a little overkill. Since it remains to reside in the same 
>>repo, why separate jira system? I thought other means in the list are good 
>>enough to separate the dev, maintaince and release activities.
Regards,Kai
--发件人：Owen 
O'Malley <owen.omal...@gmail.com>发送时间：2018年3月21日(星期三) 02:21收件人：Hdfs-dev 
<hdfs-dev@hadoop.apache.org>主　题：[VOTE] Adopt HDSL as a new Hadoop subproject
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

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Arpit Agarwal]

+1 (binding)

Arpit

On 3/20/18, 11:21 AM, "Owen O'Malley"  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

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[sanjay Radia]

+1 (binding)

sanjay
> On Mar 20, 2018, at 11:20 AM, Owen O'Malley  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


-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Xiaoyu Yao]

+1 (Binding)

Xiaoyu

On 3/20/18, 11:53 AM, "Anu Engineer"  wrote:

+1 (Binding)

--Anu


On 3/20/18, 11:21 AM, "Owen O'Malley"  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



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

[Anu Engineer]

+1 (Binding)

--Anu


On 3/20/18, 11:21 AM, "Owen O'Malley"  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



-
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org

[VOTE] Adopt HDSL as a new Hadoop subproject

[Owen O'Malley]

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