Hi Owen,

  >> 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
    compatibility requirements.
    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>
    > wrote:
    > Owen mentioned making a Hadoop subproject; we'd have to
    > > hash out what exactly this means (I assume a separate repo still managed
    > by
    > > 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

Reply via email to