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 <cdoug...@apache.org> wrote: > On Thu, Mar 22, 2018 at 10:23 AM, Andrew Wang <andrew.w...@cloudera.com> > 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" <cdoug...@apache.org> 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 <andrew.w...@cloudera.com> >> 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 <owen.omal...@gmail.com> >> wrote: >>> All, >>> >>> Following our discussions on the previous thread (Merging branch HDFS-7240 >>> to trunk), I'd like to propose the following: >>> >>> * HDSL become a subproject of Hadoop. >>> * HDSL will release separately from Hadoop. Hadoop releases will not >>> contain HDSL and vice versa. >>> * HDSL will get its own jira instance so that the release tags stay >>> separate. >>> * On trunk (as opposed to release branches) HDSL will be a separate module >>> in Hadoop's source tree. This will enable the HDSL to work on their trunk >>> and the Hadoop trunk without making releases for every change. >>> * Hadoop's trunk will only build HDSL if a non-default profile is enabled. >>> * When Hadoop creates a release branch, the RM will delete the HDSL module >>> from the branch. >>> * HDSL will have their own Yetus checks and won't cause failures in the >>> Hadoop patch check. >>> >>> I think this accomplishes most of the goals of encouraging HDSL >>> development >>> while minimizing the potential for disruption of HDFS development. >>> >>> The vote will run the standard 7 days and requires a lazy 2/3 vote. PMC >>> votes are binding, but everyone is encouraged to vote. >>> >>> +1 (binding) >>> >>> .. Owen >> >> --------------------------------------------------------------------- >> 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
