Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] RFC: merge windows branch into trunk
From: Rainer Keller (keller_at_[hidden])
Date: 2008-12-10 16:01:41


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

Now we are ready to commit and just as well get a r20106 which touches quite a
code-base once again ,-]

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