>> 1. It is hard to tell what has changed. git rebase -i tells me the
>> branch has 722 commits. The rebase failed with a conflict. It would really
>> help if you rebased to current trunk.
Thanks for the comments. I have merged trunk to HDFS-7240 branch.
Hopefully, this makes it easy to look at the changes; I have committed the
change required to fix the conflict as a separate commit to make it easy for
you to see.
On 3/2/18, 4:42 PM, "Wangda Tan" <wheele...@gmail.com> wrote:
I like the idea of same source / same release and put Ozone's source under
a different directory.
Like Owen mentioned, It gonna be important for all parties to keep a
regular and shorter release cycle for Hadoop, e.g. 3-4 months between minor
releases. Users can try features and give feedbacks to stabilize feature
earlier; developers can be happier since efforts will be consumed by users
soon after features get merged. In addition to this, if features merged to
trunk after reasonable tests/review, Andrew's concern may not be a problem
bq. Finally, I earnestly believe that Ozone/HDSL itself would benefit from
being a separate project. Ozone could release faster and iterate more
quickly if it wasn't hampered by Hadoop's release schedule and security and
On Fri, Mar 2, 2018 at 4:24 PM, Owen O'Malley <owen.omal...@gmail.com>
> On Thu, Mar 1, 2018 at 11:03 PM, Andrew Wang <andrew.w...@cloudera.com>
> Owen mentioned making a Hadoop subproject; we'd have to
> > hash out what exactly this means (I assume a separate repo still managed
> > the Hadoop project), but I think we could make this work if it's more
> > attractive than incubation or a new TLP.
> Ok, there are multiple levels of sub-projects that all make sense:
> - Same source tree, same releases - examples like HDFS & YARN
> - Same master branch, separate releases and release branches - Hive's
> Storage API vs Hive. It is in the source tree for the master branch,
> has distinct releases and release branches.
> - Separate source, separate release - Apache Commons.
> There are advantages and disadvantages to each. I'd propose that we use
> same source, same release pattern for Ozone. Note that we tried and later
> reverted doing Common, HDFS, and YARN as separate source, separate release
> because it was too much trouble. I like Daryn's idea of putting it as a
> level directory in Hadoop and making sure that nothing in Common, HDFS, or
> YARN depend on it. That way if a Release Manager doesn't think it is ready
> for release, it can be trivially removed before the release.
> One thing about using the same releases, Sanjay and Jitendra are signing
> to make much more regular bugfix and minor releases in the near future.
> example, they'll need to make 3.2 relatively soon to get it released and
> then 3.3 somewhere in the next 3 to 6 months. That would be good for the
> project. Hadoop needs more regular releases and fewer big bang releases.
> .. Owen