0.10 release process - time based release?

[Robert Collins]

On Tue, 2006-08-01 at 18:29 +1000, Michael Ellerman wrote:


> Sounds good to me. The problem I have with the current situation is
> that features seem to land faster just before a release, which is
> exactly backwards. Your proposal should fix that.
> 
> My only worry would be that it will leave larger changes sitting out
> in the wild, untested. So I'd propose that in the first 3 weeks,
> pretty much anything good gets merged, that way it gets testing and
> attention, but if it turns out to be not 100% it comes out before
> release.

Well, I think merges should still pass all the normal quality criteria.
Theres nothing saying that features outside the 'feature goals' cannot
be merged. In fact, I would expect that anything meeting the quality
criteria still be merged as normal.

Larger changes that are not ready by the freeze date just carry over to
the next release - which is just two more weeks away to start their
merge, so no problem.

The other thing that can and should be done with larger changes is
turning them into a series of smaller changes which can pass review.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060802/06af378f/attachment-0001.pgp