Historically, our rules have prohibited the introduction of such
features into a sub-release like 1.3.1. Perhaps that policy needs
We've been pretty strict about it in the past, though...with some good
reasons, I admit.
On Nov 20, 2008, at 4:56 PM, Rainer Keller wrote:
> Hi Ralph,
> On Donnerstag, 20. November 2008, Ralph Castain wrote:
>> 1. since nearly everyone is at SC08, and since next week is a
>> 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
>> 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
> 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
> 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
> 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