The issue in 1.7 is all the cross-integration, which means we violate our normal behavior when it comes to no-building and user-directed component selection. Jeff and I just discussed how this could be resolved using the PML-BTL model, but (a) that is not what we have in 1.7, and (b) it isn't clear to me how hard it will be to do, and when it might be ready.
However, we don't have the problem of incorrect results that we do in the trunk, so we do have a little more latitude. So the situation with respect to 1.7 is pretty clear: if we can get a PML-BTL model in place within the next week, then we can let things continue as-is. If we can't, then we remove the coll/ml component and the bcol framework from 1.7, leaving the door open to reinstatement whenever the code is actually ready. On Feb 7, 2014, at 7:37 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > How is this a problem in 1.7? We don't have a .ompi_ignore in > 1.7.4. That is there to prevent mtt failures while I fix some > outstanding bcol issues. > > I will clean this up on trunk and add it to the cmr. > > -Nathan > > On Thu, Feb 06, 2014 at 08:42:27PM -0800, Ralph Castain wrote: >> As many of you will have noticed, I have been struggling most of the evening >> with breakage on the trunk. This was initiated by adding .ompi_ignore to the >> coll/ml component, but the root cause of the problem is a blatant disregard >> for OMPI design rules in the bcol framework. Component-level headers from >> the coll/ml area have been included in multiple places throughout the bcol >> framework, making it impossible to separate these two areas. >> >> Unfortunately, this problem has now been propagated to the 1.7 branch. As >> release manager, I'm afraid that places me in a difficult position, and I'm >> going to have to insist that this either is fixed immediately (i.e., in next >> 24 hours), or I have to rescind/delete that area from the 1.7 branch and >> release an immediate 1.7.5 (with attendant apologies to the community for >> the screwup). We will then proceed with our intended plan, minus the bcol >> code. >> >> I'd appreciate someone letting me know if this problem (a) can even be >> fixed, given the degree of cross-connection I see in the bcol code, and (b) >> if it can, then by when. >> >> Thanks >> Ralph >> >> >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
