hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wangda Tan <wheele...@gmail.com>
Subject Re: [VOTE] Merging branch HDFS-7240 to trunk
Date Sat, 03 Mar 2018 00:41:22 GMT
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.omalley@gmail.com>

> On Thu, Mar 1, 2018 at 11:03 PM, Andrew Wang <andrew.wang@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, but
>    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 the
> 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 top
> 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 up
> to make much more regular bugfix and minor releases in the near future. For
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message