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: Ralph Castain (rhc_at_[hidden])
Date: 2008-12-10 16:11:35


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/
>>> tmattox_at_[hidden] || timattox_at_[hidden]
>>> I'm a bright... http://www.the-brights.net/
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> 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: keller_at_[hidden]
> Germany AIM/Skype:rusraink
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel