Terry, Rich and I talked about this a little bit in Chicago at the Forum
meeting.
It's not yet clear what is the Right direction to go here. We certainly don't
want to go another 8 months before releasing 1.5.1.
On Oct 11, 2010, at 9:32 AM, Graham, Richard L. wrote:
> Why go to all this effo
Why go to all this effort, and not just fork 1.7 from the trunk, skipping the
whole merge process ? Seems like it would be much more prudent to spend time
on improving the code base, adding missing MPI support, etc., rather than
spending the time on a merge.
Rich
On 10/8/10 6:34 PM, "Jeff
On 10/11/2010 06:11 AM, Jeff Squyres wrote:
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
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 de
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 w
On Oct 8, 2010, at 5:36 PM, Ralph Castain wrote:
> I have no problem with that, but remember that it will create an ABI break
> for any third-party plugin developer.
>
> As long as we are comfortable doing that, or create the
> backward-compatibility we discussed, then this plan is fine by me.
I have no problem with that, but remember that it will create an ABI break for
any third-party plugin developer.
As long as we are comfortable doing that, or create the backward-compatibility
we discussed, then this plan is fine by me.
On Oct 8, 2010, at 3:13 PM, Jeff Squyres wrote:
> As we d
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
