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