Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] 1.3 branch
From: Ralph Castain (rhc_at_[hidden])
Date: 2008-07-24 15:12:38

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 think should go over to 1.3 yet, if at all!

Good luck sorting it all out - I figure I'll just worry about making
the trunk work and leave the 1.3 transition issues to you brighter
minds. ;-)

On Jul 24, 2008, at 12:00 PM, Terry Dontje wrote:

> 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 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. :-)
> To beat this horse into the ground. A good example is the latest
> performance regression due to the paffinity changes. If you were
> testing on RH 5.1 you would not have found the problem. And I think
> that is true with a lot of our changes in that we test on a limited
> set of platforms locally so there is definitely a risk here.
> So you can stand by the "Do the right thing" mantra but at the same
> time we need to realize problems will happen and the only way to
> reduce them is by shrinking the window of ambiguity.
> --td
>> 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
>>>>> devel_at_[hidden]
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]