July 2012 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Internal consensus cannot include changes to the approved branch. On Sun, 22 Jul 2012, Torsten Hoefler wrote: > Bronis, >> I do not recall the discussion and your choice to >> omit the forum list is arbitrary and unnecessary. > Your choice was to not be in the room at that time :-). The RMA working > group is trying to achieve internal consensus before getting to the > Forum. This has been the most successful modus operandi so far. The > working group is open to anyone. You are welcome to contribute to the > technical discussion. > > Torsten > > -- > ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 >

1 0

Re: [Mpi-forum] [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

On Sun, Jul 22, 2012 at 10:10:36AM -0700, Bronis R. de Supinski wrote: > > Internal consensus cannot include changes to the approved branch. Again, the changes were approved by the Forum and they are still committed. Torsten -- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi-forum] [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Torsten: I do not recall the discussion and your choice to omit the forum list is arbitrary and unnecessary. Bronis On Sun, 22 Jul 2012, Torsten Hoefler wrote: > Bronis, > >> It is too large of a change for a chapter committee just to add. >> In the least, you need to poll the full forum list. > I disagree, this is part of a change that we discussed at the Forum and > the Forum agreed. However, after that, the WG started to discuss > internally. So we have the Forum's approval but are not sure what to do > :-). > > I have really no strong opinion one way or another, just waiting for > instructions. > > Torsten > > -- > ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 >

1 0

Re: [Mpi-forum] [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

Bronis, > I do not recall the discussion and your choice to > omit the forum list is arbitrary and unnecessary. Your choice was to not be in the room at that time :-). The RMA working group is trying to achieve internal consensus before getting to the Forum. This has been the most successful modus operandi so far. The working group is open to anyone. You are welcome to contribute to the technical discussion. Torsten -- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by William Gropp 22 Jul '12

22 Jul '12

Are these MPI_T_ERR_xxx codes or are they classes? The MPI_ERR_xx list is of classes, not codes (classes may be used as codes but codes may or may not be a class). Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Jul 22, 2012, at 4:54 AM, Bronis R. de Supinski wrote: > > Rolf: > > Re: >> Dear Bronis, Martin, Dave, and Kathryn, >> (Profiling/Tools chapter responsibles) >> >> (you may forward this to the tools list - I'm not on that list) >> >> Two important questions: >> >> 1. Alexander Supalov detected that we did it wrong: >> The MPI_T_ERR_... list must be part of the total error >> list and sorted in before MPI_ERR_LASTCODE. >> >> I will change this in chap-appLang/appLang-Const.tex >> >> Please look, if there must be some additional wording on this. >> For example, the last sentence of Section 14.3.9 >> >> "All return codes with the prefix MPI_T_ must be unique values and >> cannot overlap with any other return values returned by the MPI >> implementation." > > The above wording clearly states that the return values > should be consistent with MPI_ERR_* return values. So, > either the above wording needs to change (I do not see > why MPI_T_* return values need to be distinct from > MPI_ERR_* return values since the user should know that > they were using an MPI_T_* function) or we need to adopt > something like what you suggest. > > I think we need broader opinions to make the decision. > > I am concerned that wrapping up the document for MPI 3.0 > has led to a fast and loose attitude about making broader > changes "in order to get it done." This attitude can > easily lead to suboptimal solutions. > > Bronis > > > >> may be modified into >> >> "All return codes with the prefix MPI_T_ must be unique values and >> cannot overlap with any other return values returned by the MPI >> implementation and satisfy >> >> 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " >> >> or >> 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= MPI_ERR_LASTCODE. >> >> or >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. >> >> and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also repeated >> in Table 14.5 as last entry, as done for the first value MPI_SUCCESS. >> >> This proposal is based on Section 8.4, the sentence >> >> "The error codes satisfy, >> 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " >> >> Please confirm, that Alexander is right, >> please include me in your discussion and >> please tell me your result >> that I can do the correct changes in chap-appLang >> and you in chap-tools. >> >> 2. Qeustion is less important; it is about naming: >> Alexander also noticed that your names do not fit to the names >> used in the past: >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use abbrevations) >> >> or >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use abbrevations) >> >> In most cases, we do not combine words without underscore. >> >> As far as I see, you can do the underscores. >> Be sure to stay at maximum with 30 characters. >> >> Current longest MPI_T constants: >> >> 123456789012345678901234567890 >> MPI_T_PVAR_CLASS_HIGHWATERMARK >> MPI_T_PVAR_CLASS_LOWWATERMARK >> MPI_T_VERBOSITY_MPIDEV_DETAIL >> >> Based on this, I would stay with you names based on your MPI_T rule: >> MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> >> >> i.e., I would only change >> >> MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT >> >> Please tell me also your decision >> that I can do the correct changes in chap-appLang >> and you in chap-tools. >> >> Best regards >> Rolf >> >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] MPI_INFO_GET_ENV naming question
by Rolf Rabenseifner 22 Jul '12

22 Jul '12

Martin, Can we take this as a decision? So far there is no objection. It must be changed in tools and appLang, therefore, I need a clear decision for appLang (as chapter author). Please tell. Best regards Rolf ----- Original Message ----- > From: "William Gropp" <wgropp(a)illinois.edu> > To: "Martin Schulz" <schulzm(a)llnl.gov>, "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Friday, July 20, 2012 6:11:41 PM > Subject: Re: [Mpi-forum] MPI_INFO_GET_ENV naming question > I prefer MPI_INFO_ENV . Using GET in the name will be confusing. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Jul 19, 2012, at 12:25 PM, Schulz, Martin wrote: > > > Hi all, > > > > During the chapter review for Chapter 8, the environment chapter, a > > question came up at the forum, which we thought requires wider > > feedback. > > > > Ticket 313 introduced an info object into MPI 3.0 that allows users > > to query the environment, which is called MPI_INFO_GET_ENV. This > > name, however, contains a verb and hence follows the naming > > structure of an MPI function, but is a constant. Hence, should we > > really go with this name or should we rename this into a name > > without a verb, like MPI_INFO_ENV, to avoid confusion? People in the > > room were leaning towards the latter and this is clearly ticket 0 at > > this point, but we wanted to ask to make sure there is no unintended > > impact with that change. > > > > Comments? > > Thanks, > > > > Martin > > > > > > ________________________________________________________________________ > > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-forum] MPI-3: MPI_T_ERR_... and MPI_ERR_LASTCODE
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Rolf: Re: > Dear Bronis, Martin, Dave, and Kathryn, > (Profiling/Tools chapter responsibles) > > (you may forward this to the tools list - I'm not on that list) > > Two important questions: > > 1. Alexander Supalov detected that we did it wrong: > The MPI_T_ERR_... list must be part of the total error > list and sorted in before MPI_ERR_LASTCODE. > > I will change this in chap-appLang/appLang-Const.tex > > Please look, if there must be some additional wording on this. > For example, the last sentence of Section 14.3.9 > > "All return codes with the prefix MPI_T_ must be unique values and > cannot overlap with any other return values returned by the MPI > implementation." The above wording clearly states that the return values should be consistent with MPI_ERR_* return values. So, either the above wording needs to change (I do not see why MPI_T_* return values need to be distinct from MPI_ERR_* return values since the user should know that they were using an MPI_T_* function) or we need to adopt something like what you suggest. I think we need broader opinions to make the decision. I am concerned that wrapping up the document for MPI 3.0 has led to a fast and loose attitude about making broader changes "in order to get it done." This attitude can easily lead to suboptimal solutions. Bronis > may be modified into > > "All return codes with the prefix MPI_T_ must be unique values and > cannot overlap with any other return values returned by the MPI > implementation and satisfy > > 0 = MPI_SUCCESS < MPI_T_ERR_... <= MPI_ERR_LASTCODE. " > > or > 0 = MPI_SUCCESS < MPI_ERR_... < MPI_T_ERR_... <= MPI_ERR_LASTCODE. > > or > 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE < MPI_T_ERR_... <= MPI_T_ERR_LASTCODE. > > and the MPI_ERR_LASTCODE and/or MPI_T_ERR_LASTCODE may be also repeated > in Table 14.5 as last entry, as done for the first value MPI_SUCCESS. > > This proposal is based on Section 8.4, the sentence > > "The error codes satisfy, > 0 = MPI_SUCCESS < MPI_ERR_... <= MPI_ERR_LASTCODE: " > > Please confirm, that Alexander is right, > please include me in your discussion and > please tell me your result > that I can do the correct changes in chap-appLang > and you in chap-tools. > > 2. Qeustion is less important; it is about naming: > Alexander also noticed that your names do not fit to the names > used in the past: > > MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT (we do not use abbrevations) > > or > > MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOT_INIT (we do not use abbrevations) > > In most cases, we do not combine words without underscore. > > As far as I see, you can do the underscores. > Be sure to stay at maximum with 30 characters. > > Current longest MPI_T constants: > > 123456789012345678901234567890 > MPI_T_PVAR_CLASS_HIGHWATERMARK > MPI_T_PVAR_CLASS_LOWWATERMARK > MPI_T_VERBOSITY_MPIDEV_DETAIL > > Based on this, I would stay with you names based on your MPI_T rule: > MPI_T_<structual-areas-with-underscores>_<final-name-without-underscores> > > i.e., I would only change > > MPI_T_ERR_CANTINIT --> MPI_T_ERR_CANNOTINIT > > Please tell me also your decision > that I can do the correct changes in chap-appLang > and you in chap-tools. > > Best regards > Rolf > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >

1 0

Re: [Mpi-forum] Final document of the night
by Schulz, Martin 20 Jul '12

20 Jul '12

Hi Rajeev, On Jul 20, 2012, at 4:30 PM, Rajeev Thakur wrote: > The current svn version is 1496 and it doesn't build. > > % make > fig2dev -L pdftex -p 1 figures/context-fig-1.fig figures/context-fig-1.pdf > make: fig2dev: No such file or directory > make: *** [figures/context-fig-1.pdf] Error 1 I had the same issue and hat to install fig2dev (in case you are on a Mac using mac ports, it's the transfig package). This seems to be a new dependency introduced in one of the recent versions. Martin > > > On Jul 20, 2012, at 6:00 PM, Jeff Squyres wrote: > >> I posted new copies of the document as of Friday evening, 7pm US Eastern time, July 20, 2012. SVN r1455: >> >> http://www.open-mpi.org/~jsquyres/unofficial/ >> >> >> On Jul 19, 2012, at 10:37 AM, Supalov, Alexander wrote: >> >>> Hi Jeff, >>> >>> Thank you. Do you happen to have the marked-up version as well somewhere? >>> >>> Best regards. >>> >>> Alexander >>> >>> -----Original Message----- >>> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres >>> Sent: Thursday, July 19, 2012 2:25 PM >>> To: MPI Forum list >>> Subject: [Mpi-forum] Final document of the night >>> >>> Yesterday at the Forum, we utilized the power of having a few dozen people sitting together in a room and did a LOT of text/ticket/chapter reviews. This resulted in finding a LOT of little issues (and a few big ones). If chapter committee members were in the room, they fixed and committed the text. But for committees that had no representatives in the room, we made the executive decision to make the fixes ourselves, review them, and then commit them. >>> >>> This really helped keep the momentum going, and we made a TREMENDOUS amount of progress yesterday. I apologize if this caused some consternation to chapter authors/committees who were not in the room. >>> >>> ### Please review SVN commit logs and ensure that everything is ok in your chapter. >>> >>> ### Chapter committees *NEED* to do whole-chapter reviews to ensure that everything is a good, consistent state. As Bill mentioned, use the "cleandoc" build. >>> >>> *** To those who were in the room: Thank you thank you thank you for all the reviewing yesterday! >>> >>> I have uploaded a final cleandoc PDF from last night: >>> >>> http://www.open-mpi.org/~jsquyres/unofficial/mpi-report-cleandoc-r1455.pdf >>> >>> Here's the specific items I'm aware of that still need to be done (I'm sure there are other things, too): >>> >>> 1. The names and organizations in the front matter need to be updated (I sent Bill the info yesterday) 2. Change log is still being edited (there's still lots of issues with it; don't bother reviewing it until Rolf has committed a new version) 3. There's 1 last C++ type still showing up in the index; Rolf will fix it 4. Ticket #313 5. Chapter committees need to have final chapter reviews and bless their chapters as "done!" >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> Intel GmbH >>> Dornacher Strasse 1 >>> 85622 Feldkirchen/Muenchen, Deutschland >>> Sitz der Gesellschaft: Feldkirchen bei Muenchen >>> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, Christian Lamprechter >>> Registergericht: Muenchen HRB 47456 >>> Ust.-IdNr./VAT Registration No.: DE129385895 >>> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] Final document of the night
by Rajeev Thakur 20 Jul '12

20 Jul '12

The current svn version is 1496 and it doesn't build. % make fig2dev -L pdftex -p 1 figures/context-fig-1.fig figures/context-fig-1.pdf make: fig2dev: No such file or directory make: *** [figures/context-fig-1.pdf] Error 1 On Jul 20, 2012, at 6:00 PM, Jeff Squyres wrote: > I posted new copies of the document as of Friday evening, 7pm US Eastern time, July 20, 2012. SVN r1455: > > http://www.open-mpi.org/~jsquyres/unofficial/ > > > On Jul 19, 2012, at 10:37 AM, Supalov, Alexander wrote: > >> Hi Jeff, >> >> Thank you. Do you happen to have the marked-up version as well somewhere? >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres >> Sent: Thursday, July 19, 2012 2:25 PM >> To: MPI Forum list >> Subject: [Mpi-forum] Final document of the night >> >> Yesterday at the Forum, we utilized the power of having a few dozen people sitting together in a room and did a LOT of text/ticket/chapter reviews. This resulted in finding a LOT of little issues (and a few big ones). If chapter committee members were in the room, they fixed and committed the text. But for committees that had no representatives in the room, we made the executive decision to make the fixes ourselves, review them, and then commit them. >> >> This really helped keep the momentum going, and we made a TREMENDOUS amount of progress yesterday. I apologize if this caused some consternation to chapter authors/committees who were not in the room. >> >> ### Please review SVN commit logs and ensure that everything is ok in your chapter. >> >> ### Chapter committees *NEED* to do whole-chapter reviews to ensure that everything is a good, consistent state. As Bill mentioned, use the "cleandoc" build. >> >> *** To those who were in the room: Thank you thank you thank you for all the reviewing yesterday! >> >> I have uploaded a final cleandoc PDF from last night: >> >> http://www.open-mpi.org/~jsquyres/unofficial/mpi-report-cleandoc-r1455.pdf >> >> Here's the specific items I'm aware of that still need to be done (I'm sure there are other things, too): >> >> 1. The names and organizations in the front matter need to be updated (I sent Bill the info yesterday) 2. Change log is still being edited (there's still lots of issues with it; don't bother reviewing it until Rolf has committed a new version) 3. There's 1 last C++ type still showing up in the index; Rolf will fix it 4. Ticket #313 5. Chapter committees need to have final chapter reviews and bless their chapters as "done!" >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> Sitz der Gesellschaft: Feldkirchen bei Muenchen >> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, Christian Lamprechter >> Registergericht: Muenchen HRB 47456 >> Ust.-IdNr./VAT Registration No.: DE129385895 >> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] Final document of the night
by Jeff Squyres 20 Jul '12

20 Jul '12

I posted new copies of the document as of Friday evening, 7pm US Eastern time, July 20, 2012. SVN r1455: http://www.open-mpi.org/~jsquyres/unofficial/ On Jul 19, 2012, at 10:37 AM, Supalov, Alexander wrote: > Hi Jeff, > > Thank you. Do you happen to have the marked-up version as well somewhere? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-forum-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres > Sent: Thursday, July 19, 2012 2:25 PM > To: MPI Forum list > Subject: [Mpi-forum] Final document of the night > > Yesterday at the Forum, we utilized the power of having a few dozen people sitting together in a room and did a LOT of text/ticket/chapter reviews. This resulted in finding a LOT of little issues (and a few big ones). If chapter committee members were in the room, they fixed and committed the text. But for committees that had no representatives in the room, we made the executive decision to make the fixes ourselves, review them, and then commit them. > > This really helped keep the momentum going, and we made a TREMENDOUS amount of progress yesterday. I apologize if this caused some consternation to chapter authors/committees who were not in the room. > > ### Please review SVN commit logs and ensure that everything is ok in your chapter. > > ### Chapter committees *NEED* to do whole-chapter reviews to ensure that everything is a good, consistent state. As Bill mentioned, use the "cleandoc" build. > > *** To those who were in the room: Thank you thank you thank you for all the reviewing yesterday! > > I have uploaded a final cleandoc PDF from last night: > > http://www.open-mpi.org/~jsquyres/unofficial/mpi-report-cleandoc-r1455.pdf > > Here's the specific items I'm aware of that still need to be done (I'm sure there are other things, too): > > 1. The names and organizations in the front matter need to be updated (I sent Bill the info yesterday) 2. Change log is still being edited (there's still lots of issues with it; don't bother reviewing it until Rolf has committed a new version) 3. There's 1 last C++ type still showing up in the index; Rolf will fix it 4. Ticket #313 5. Chapter committees need to have final chapter reviews and bless their chapters as "done!" > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer, Christian Lamprechter > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0