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
