Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: merge windows branch into trunk
From: Rainer Keller (keller_at_[hidden])
Date: 2008-11-20 18:56:34


Hi Ralph,
On Donnerstag, 20. November 2008, Ralph Castain wrote:
> 1. since nearly everyone is at SC08, and since next week is a holiday,
> the timing of this merge is poor. I would really urge that you delay
> it until at least Dec 5 so people actually know about it - and have
> time to even think about it
Yes, the idea is having more people take a look into it and try out.

> 2. how does this fit into our overall release schedule? There was talk
> at one time (when we thought 1.3 was going out soon) about having a
> short release cycle to get Windows support out for 1.4. Now this is
> coming into the trunk even before 1.3 goes out.
>
> So is 1.3 going to have a lifecycle of a month? Or are we going to
> delay 1.3 (if it even needs to be delayed) so it can include this code?
No, why ,-]?
At the appropriate time this can be merged into 1.3.x (with x being > 1...?)

> Reason I ask: last time we rolled Windows support into the system it
> created a complete code fork, making support for the current stable
> release nearly impossible. There generated a lot of unhappiness and
> argument within the community until we finally released a new version.
Well, we believe with only the view touched general files and only the CCP
components being added, there's less chance of hurting other code.

> >> M ompi/runtime/ompi_mpi_init.c
> >> ...
> >> M orte/tools/orterun/orterun.c
> >> M orte/util/hnp_contact.c
> >
> > I would ask that you consider breaking these
> > modifications into parts that "could" be harmlessly
> > brought over independently to 1.3, if a subsequent
> > non-windows bugfix to one of those files needs to
> > be brought over that will only merge cleanly if some
> > of your changes to the same file are also brought over.
> > For example, it would be a real pain to have to use
> > patchfiles to resolve merge conflicts simply because
> > of an #ifdef or white-space change here or there.
> > Hopefully that made sense...
Yes, breaking into chunks (such as the CMakeLists.txt + .windows files, the
CCP component and finally the files that touch other files) is a good way
forward.

CU,
Rainer

-- 
----------------------------------------------------------------
Dipl.-Inf. Rainer Keller   http://www.hlrs.de/people/keller
 HLRS                          Tel: ++49 (0)711-685 6 5858
 Nobelstrasse 19                  Fax: ++49 (0)711-685 6 5832
 70550 Stuttgart                    email: keller_at_[hidden]     
 Germany                             AIM/Skype:rusraink