On Tue, Mar 11, 2014 at 4:20 PM, Sean Busbey <busbey+[EMAIL PROTECTED]>wrote:
I have been reading through a lot of the comments made so far.

A release manger is a possible solution to the problem of releases
languish.   I think it would be help to list what are causing releases to

1.  Incomplete features checked in before feature freeze
2. A steady of stream of non-essential changes after feature freeze
3. Testing takes a while and has to be redone after major changes are made
4. Critical bugs found during test need to be fixed

What else other things are slowing down releases?

I am not convinced a release manager can solve these problems, my main
concern is scalability.   The 1.7.0 release manager would have to really be
on top of all of the 1.7.0 commits, even before feature freeze.  If the
release manager does not deal w/ incomplete features early, it will be much
harder to deal with them later.  W/ CTR commits can come in faster than the
release manager can process them.   This make me think of the benevelont
dictator model where only the 1.7.0 RM merges things into 1.7.0-SNAPSHOT.
They can do this as they have time.   I have been looking at Gerrit a bit
lately.  I have never used it, but I like what I have read.  It seems like
gerrit is better than RB because its more automated w/ less friction.
Using Gerrit and RTC would be more scalable than a single RM.

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB