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
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
