> 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
