On Dec 10, 2008, at 2:01 PM, Rainer Keller wrote:
Ralph,
we delayed the COB for this to 9.12., announced yesterday to prepare
to commit
today.
We updated to get new buglets that were fixed, tested twice on Win
(shared&static) and Linux to see that nothing breaks
Sounds great!
Now we are ready to commit and just as well get a r20106 which
touches quite a
code-base once again ,-]
Actually, r20106 is pretty well confined to the iof area (the changes
outside iof are rather trivial) and mostly just restores what was
there a few days ago. So I would be surprised to see a conflict other
than perhaps how Windows handles iof.
Glad to see this come over! Should be an interesting few days of MTT
results... :-))
Ralph
Thanks,
Rainer
On Donnerstag, 20. November 2008, Ralph Castain wrote:
Hmmm....I was just typing this up when Tim's note hit. I also have
two
concerns that somewhat echo his:
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
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?
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.
From what I have seen as we've discussed things during devel, these
are fairly well-contained changes. However, it -will- make
maintaining
1.3 more difficult if people attempt to do it the old way - making
changes in the trunk and patching across to 1.3. If we instead use
isolated 1.3 branches for maintaining the code, then this isn't an
issue.
Merits more thought than one week can provide.
Ralph
On Nov 20, 2008, at 6:53 AM, Tim Mattox wrote:
I have two concerns. First is that we really need to focus on
getting 1.3 stable and released. My second concern with
this is how will it effect merging of bugfixes for 1.3 from the
trunk once we release 1.3. Will the following modified files
cause merge conflicts for CMRs? How big is this diff,
can you send it to the list, or otherwise make it available?
M ompi/runtime/ompi_mpi_init.c
M opal/event/event.c
M opal/event/WIN32-Code/win32.c
M opal/mca/base/mca_base_param.c
M opal/mca/installdirs/windows/opal_installdirs_windows.c
M opal/runtime/opal_cr.c
M opal/win32/ompi_misc.h
M opal/win32/win_compat.h
M orte/mca/plm/ccp/plm_ccp_component.c
M orte/mca/plm/ccp/plm_ccp_module.c
M orte/mca/plm/process/plm_process_module.c
M orte/mca/ras/ccp/ras_ccp_component.c
M orte/mca/ras/ccp/ras_ccp_module.c
M orte/runtime/orte_wait.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...
Although I don't use windows myself, I appreciate your
and others' efforts to expand the number of platforms
we can run on. Great work!
--
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
tmat...@gmail.com || timat...@open-mpi.org
I'm a bright... http://www.the-brights.net/
_______________________________________________
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
--
----------------------------------------------------------------
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
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
