Hi Rainer
Historically, our rules have prohibited the introduction of such
features into a sub-release like 1.3.1. Perhaps that policy needs
review?
We've been pretty strict about it in the past, though...with some good
reasons, I admit.
Ralph
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
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: kel...@hlrs.de
Germany AIM/Skype:rusraink
