On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans eev...@rackspace.com wrote:
On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans eev...@rackspace.com wrote:
The discussion seems to be petering out and I wonder if that means folks
are still trying
On Thu, 2011-01-20 at 10:19 -0800, Ryan King wrote:
On Thu, Jan 20, 2011 at 8:39 AM, Eric Evans eev...@rackspace.com wrote:
On Wed, 2011-01-19 at 10:29 -0600, Jonathan Ellis wrote:
On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans eev...@rackspace.com wrote:
The discussion seems to be petering
On Tue, Jan 18, 2011 at 12:36 PM, Eric Evans eev...@rackspace.com wrote:
The discussion seems to be petering out and I wonder if that means folks
are still trying to wrap their heads around everything, or if we have
consensus.
If we're in agreement on 4 months between releases, and
On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote:
Everyone on chrome commits to trunk first. I think the important
change we could make is to keep everyone closer to trunk. We spend a
good deal of effort back-porting patches between major versions. I
think we should make the major
On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote:
# Fixed schedule
We should set a fixed schedule and stick to it. Anything features not
ready at branch time won't make it and will be disabled in the stable
branch.
In general, I agree, if we want a cadence, we're going to have to exert
I think many believe that shipping 0.7 took longer than it should.
Rather than going into why that happened, I'd like to propose a better
way to move forward that will hopefully allow us to ship on a more
predictable schedule. This proposal is heavily influenced by the
google chrome release
To be more clear, here's what I think is broken in the current release planning:
1. The dates are wildly unpredictable
2. People aren't allowed to work against trunk on features for
multiple iterations (see #1072)
3. Stable branches diverge too much, causing duplicated effort. (we
essentially
On Thu, Jan 13, 2011 at 2:32 PM, Ryan King r...@twitter.com wrote:
# Fixed schedule
We should set a fixed schedule and stick to it. Anything features not
ready at branch time won't make it and will be disabled in the stable
branch.
I like this idea, as long as we're willing to be flexible
On Thu, Jan 13, 2011 at 4:04 PM, Jonathan Ellis jbel...@gmail.com wrote:
On Thu, Jan 13, 2011 at 2:32 PM, Ryan King r...@twitter.com wrote:
# Fixed schedule
We should set a fixed schedule and stick to it. Anything features not
ready at branch time won't make it and will be disabled in the
