Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [DISCUSSION] Release process

Copy link to this message
Re: [DISCUSSION] Release process
Getting a release out is critical.  Otherwise, IMO, the project is
dead but for the stiffening.

Thanks Tom for stepping up to play the RM role for a 0.21.

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?).

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.  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

I'd be interested in more discussion of the latter point and in what
the community thinks we can do to address the current, IMO,
stasis-making set of circumstances.


On Thu, Mar 25, 2010 at 6:22 AM, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Tom White wrote:
>> I agree that getting the release process restarted is of utmost
>> importance to the project. To help make that happen I'm happy to
>> volunteer to be a release manager for the next release. This will be
>> the first release post-split, so there will undoubtedly be some issues
>> to work out. I think the focus should be on getting an alpha release
>> out, so I suggest we create a new 0.21 branch from trunk, then spend
>> time fixing blockers (which will be a superset of the existing 0.21
>> blockers).
>> Cheers,
>> Tom
> My thoughts
> * The installed base creates its own inertia: if you have 2PB of data you
> care about, you don't want to be bleeding edge.
> * That installed base creates resistance to getting patches back in. I think
> everyone -myself included -has stuff they want to get into the system, but
> everyone who doesn't see the need for a feature is nervous.
> * the branches reassure people of stability, but increase the cost of
> changes and fixes too. There's more pressure to backport stuff, this makes
> big reorgs hard.
> * It makes takeup of new features (like the new FS apis) harder. You have to
> consider how long 0.20.x will stay around, so focus on the stuff that's
> there.
> * I worry that the partioning of the project is making inertia worse too,
> harder to co-ordinate changes across the code, and the code is still tightly
> coupled enough that matters.
> My suggestons
> +1 to the idea of stable/unstable, though I'd like to get some stuff into
> 0.22, and with avro and security, that's going to be pretty traumatic too.
> the move from 0.20 to 0.21 will be much less painful
> +1 to Tom being release manager.
> +1 to some session where everyone brings their patches up to date and we
> push them into trunk, to bring the branches back in line. If you want to do
> some session in the bay area then perhaps those of us outside it can skype
> in or IPC, do a distributed triage run and really work hard to get stuff in
> and working. We should do this before cutting the 0.21 branch, I will sort
> my stuff out asap
> Now, what cluster time -real and virtual- to people have to offer Tom? I may
> -repeat may- be able to sort out some OpenCirrus machines, or transient VMs
> with limited per-VM storage in my little 1000 node datacentre, though
> networking complexity gets in the way there. He won't have direct access to
> it.
> -Steve
>> On Wed, Mar 24, 2010 at 1:27 PM, Brian Bockelman <[EMAIL PROTECTED]>
>> wrote:
>>> Hey Allen,
>>> Your post provoked a few thoughts: