Re: [VOTE] Adopt HDSL as a new Hadoop subproject
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'Malleywrote: > > 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
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
+1 for the sub-project idea. Thanks to everyone that contributed! Regards, Rakesh On Tue, Mar 27, 2018 at 4:46 PM, Jack Liuwrote: > +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
+1 (non-binding) On Tue, Mar 27, 2018 at 2:16 AM, Tsuyoshi Ozawawrote: > +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
+1 Best, On Mon, Mar 26, 2018 at 10:38 AM, Xiao Chenwrote: > +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
+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
+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
+1 (binding) Happy to see the community converge on a proposal. On Fri, Mar 23, 2018 at 11:18 AM, Andrew Wangwrote: > +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
+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 Battulawrote: > +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
+1 ( binding) On Tue, Mar 20, 2018 at 11:50 PM, Owen O'Malleywrote: > 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
+1 (binding) Thanks! On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malleywrote: > 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
+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
+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
+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
+1 (non-binding). Thanks, Chen > On Mar 20, 2018, at 11:20 AM, Owen O'Malleywrote: > > 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
+1 (Binding) Regards, Suresh On Tue, Mar 20, 2018 at 11:20 AM, Owen O'Malleywrote: > 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
+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
> 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
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
On Thu, Mar 22, 2018 at 11:09 AM, Lei Xuwrote: > > 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
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 Douglaswrote: > 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
On Thu, Mar 22, 2018 at 10:23 AM, Andrew Wangwrote: > 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
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
+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 Wangwrote: > 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
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
+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
+1 (binding) Tsz-Wo On Wednesday, March 21, 2018, 10:38:03 PM PDT, Jakob Homanwrote: +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
+1 (binding) On 21 March 2018 at 20:12, Shashikant Banerjeewrote: > +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
+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
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
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
+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
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
+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
+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
+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
+1 (binding) sanjay > On Mar 20, 2018, at 11:20 AM, Owen O'Malleywrote: > > 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
+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
+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
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