On 10/11/2010 06:11 AM, Jeff Squyres wrote:
I don't have my half bake features in the trunk, yet :-).
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?
Did I misunderstand the commitment we had for quick dot feature
releases earlier this year? The above sounds like we'll repeat the
1.5.0 release schedule and possibly end up not releasing 1.5.1 until
8 months from now. Unless the trunk doesn't have any major
features/changes I'd almost be more inclined to say the stablization
of the trunk merge be the 1.5.1 release and plan for a 1.5.2 based
on CMRs (no CMR no putback to 1.5.2). However, that is really
dependent on the merge happening and what amount of wide spread
changes that end up being put back into the trunk that makes
backporting to 1.5 branch difficult to impossible. I would even be
somewhat supportive of periodic trunk sync ups to alleviate such
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
Terry D. Dontje | Principal Software Engineer
Engineering | +1.781.442.2631
Oracle - Performance
95 Network Drive,
Burlington, MA 01803