0.10 release process - time based release?
robertc at robertcollins.net
Wed Aug 2 00:06:15 BST 2006
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
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.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060802/06af378f/attachment-0001.pgp
More information about the bazaar