On Oct 10, 2010, at 7:49 AM, Terry Dontje wrote:
> At first glance this sounds like a sane approach but didn't we start with this same approach with 1.5.0? I know it was kind of required to do it for 1.5.0 but we did go off track with delivery. I believe to be successful at making a deadline for 1.5.1 we need to consider the following. Do we think the initial stablization is going to take weeks or months?
I *think* weeks. The trunk is pretty stable right now. But then again, that's why I'm asking here -- what do others think? Are there half-baked features in the trunk that are not / nowhere near ready for the v1.5.1?
> While we stablize what will be the rules of doing CMRs to 1.5.1? What will be the rules for doing CMRs to 1.5.1 after stablization?
I think the CMRs will be pretty much the same. However, we do reserve the right to have the more aggressive CMRs -- e.g., something "big" can be "ok, Terry/CMR committer, you have the v1.5 branch for 3 days. Bring your feature over to it." (might not be necessary if we re-sync, but we still reserve the right to do it ;-) ).
> On 10/8/2010 5:13 PM, Jeff Squyres wrote:
>> As we discussed on the call last week, since there is already a bit of a divergence between the trunk and the v1.5 branch, how's this for a wild idea:
>> What if we re-sync the entire trunk to the v1.5 branch, stabilize that,
>> and call it v1.5.1?
>> The assumption here is that it will be [far] easier to just re-sync the trunk to the v1.5 branch than to try to bring over stuff in a piecemeal fashion.
>> There's a *bunch* of new stuff on the trunk that is not on the v1.5 branch -- there's more than enough "meat" to call it a new release.
>> *** Put differently: is there anything on the trunk that is *not* ready to go to the v1.5 series?
> devel mailing list
For corporate legal information go to: