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/paffinity issue, even though we thought at each commit,
"yep, that's it. This commit will fix the problem." Looking back, we
obviously missed some things during that process, but we didn't
realize that at the time, even though we were being as careful as we
could.
If I could be so bold -- I think that's what Terry was asking: how are
we supposed to know?
My $0.02: how to know "it really solves the problem without
introducing new ones" is a really, really hard determination. Even
for very small code changes. :-)
On Jul 24, 2008, at 10:44 AM, George Bosilca wrote:
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 to solve without introducing new ones) is a
good decision metric.
george.
On Jul 24, 2008, at 3:55 PM, Terry Dontje wrote:
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 versus amount of code a change.
--td
George Bosilca wrote:
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 we should do the
best efforts to keep it that way as long as possible.
Please allows few days of testing time before moving your patches
from the trunk to the 1.3.
george.
------------------------------------------------------------------------
_______________________________________________
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
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
