Sounds like a real simple s/OPAL/OMPI fix, so I'll give it a go tonight.
On Mon, Jun 1, 2009 at 2:17 PM, Jeff Squyres wrote:
> I think a patch was put back to v1.3 that wasn't quite right -- I see
> pml_ob1_recvreq.h:183 and 223 have OPAL_HAVE_THREAD_SUPPORT. But
> OPAL_HAVE_THREAD_SUPPORT is
I think a patch was put back to v1.3 that wasn't quite right -- I see
pml_ob1_recvreq.h:183 and 223 have OPAL_HAVE_THREAD_SUPPORT. But
OPAL_HAVE_THREAD_SUPPORT isn't defined on the trunk -- only
OMPI_HAVE_THREAD_SUPPORT is defined.
Can someone fix?
Thanks...
--
Jeff Squyres
Cisco Systems
For those playing with the current 1.3 branch, just a little "heads
up". There is a missing commit that needs to be moved across from the
trunk that is causing the branch to simply exit after printing a
debug. I am merging the necessary patch across now, but have to
rebuild to verify before
There is another hidden danger here that has bitten us before -
namely, I challenge someone to remember that they fixed something last
week that (a) really does need to go over to 1.3, (b) hasn't already
done so, and (c) isn't now intertwined with someone else's interim fix
that they don't
Jeff Squyres wrote:
I think that this is exactly the problem -- when a developer puts
something back to the trunk, they (including me!) almost always commit
what they think is the fix to the problem. But hindsight is 20/20.
Case in point: it took Ralph and me and others over a week to fully
I think that this is exactly the problem -- when a developer puts
something back to the trunk, they (including me!) almost always commit
what they think is the fix to the problem. But hindsight is 20/20.
Case in point: it took Ralph and me and others over a week to fully
fix the SM/paffin
Terry,
I did not and I will not enforce any policy at this point. I'm
confident developers in this community can take such decisions by
themselves, without restrictions from the RM. As a hint, the most
basic common sense (make sure it compile and it really solve the
problem it is supposed
It might be worthwhile to spell out the conditions of when someone
should let changes soak or not. Considering your changeset 19011 was
putback without much soak time. I am not saying 19011 needed more soak
time just that I think it adds potential confusion as to what one really
needs to do v
Unfortunately over the last couple of days I realize that the patches
from the trunk are moved to the 1.3 too rapidly and usually without
much testing. I would like to remember to everybody that the 1.3,
while opened for community commits, is supposed to become stable at
one point and that
