hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: [DISCUSSION] Release process
Date Sat, 27 Mar 2010 00:03:11 GMT
> Thanks Tom for stepping up to play the RM role for a 0.21.

+1 Thanks Tom.

> Regarding Steve's call for what we can offer Tom to help along the
> release, the little flea hbase can test its use case on 0.21.0
> candidates and we can probably take on a few of the HDFS blockers.  I
> also like Steve's suggestion of a council to figure what makes the
> 0.21 cut (We're talking security and avro in 0.22, not 0.21 right?).

A council may not move quickly enough to make 0.21 real on a
reasonable timeframe. We need to vote on the rules we're going to
follow, but one attribute of the httpd model- giving the RM
considerable authority over what's in/out of a release- sounds like an
efficient way to effect a quick release of this long-suffering branch.
We also need to vote on backwards compatibility requirements for 0.21,
whatever form it takes (rebase or existing), since most seem to be
regarding it as unstable or not-quite-major.

> Allen in his note raises another issue beyond the release blockage
> that I believe warrants further discussion.  The "forks" maintained by
> the big contributors currently cloud (undermine?) the Apache release
> and the amount and pain involved patch wrangling is a friction on
> forward progress especially as versions deviate further.  Perhaps this
> state is inevitable when the stakes are this high, where there are new
> releases rolled out across thousands of machines carrying biz-critical
> data that cannot fail.

The Apache Hadoop community needs to have some honest discussions
about its priorities. The branches maintained and published by large
contributors are not harmful in principle, but the distance from
Apache not only imposes a burden on those involved in development, but
it can also fracture the user base. It should be a goal to minimize
the delta between distributions in the core framework and encourage
all players to stay current with the Apache project.

> Having the Apache project release reliably on
> a schedule should help especially if posted fixes get reviewed and
> committed.  Formally adopting the stable/unstable labeling could help
> too.

A fixed schedule is unrealistic. Six month releases just cause pain
for whoever is testing it, and if nobody is motivated to push the
branch to release (as in 0.21), then committers and contributors pay
the branch overhead purposelessly while users are perpetually confused
on its status. The httpd model- where anyone can call a release, but
trunk is unaffected- seems fair. It also keeps all parties focused on
keeping trunk stable enough to release on their own criteria. But we
should discuss "future" separately from 0.21. -C

Mime
View raw message