February 2021 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] problems pushing to your fork of mpi-standard
by Skjellum, Anthony 24 Feb '21

24 Feb '21

It seems to be better now--- I was really confused earlier. Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968 ________________________________ From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Wesley Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Sent: Wednesday, February 24, 2021 2:53 PM To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Cc: Wesley Bland <work(a)wesbland.com> Subject: Re: [Mpi-forum] problems pushing to your fork of mpi-standard I think GitHub is having problems right now. https://www.githubstatus.com/ Let’s give that a little time to go green again and then see if we still have trouble. On Feb 24, 2021, at 1:44 PM, Pritchard Jr., Howard via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: Hi Folks, I think we’ve run over some GitHub private repo limits. Neither Dan nor I can push/pull to/from either our mpiwg-sessions fork of the mpi-standard or forks into our personnel projects spaces. We recently invited another member to our WG sessions Github group and are suspicious we’ve gone over some kind of limit. Wesley could you check this out? At this point I can no longer update my PRs against the mpi-standard since I can’t push to my fork of the mpi-standard. Could others check this? Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] problems pushing to your fork of mpi-standard
by Wesley Bland 24 Feb '21

24 Feb '21

I think GitHub is having problems right now. https://www.githubstatus.com/ Let’s give that a little time to go green again and then see if we still have trouble. > On Feb 24, 2021, at 1:44 PM, Pritchard Jr., Howard via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > > Hi Folks, > > I think we’ve run over some GitHub private repo limits. Neither Dan nor I can push/pull to/from either our mpiwg-sessions fork of the mpi-standard or forks into our personnel projects spaces. > We recently invited another member to our WG sessions Github group and are suspicious we’ve gone over some kind of limit. > > Wesley could you check this out? > > At this point I can no longer update my PRs against the mpi-standard since I can’t push to my fork of the mpi-standard. > > Could others check this? > > Thanks, > > Howard > > -- > > Howard Pritchard > HPC-ENV > Los Alamos National Laboratory > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

problems pushing to your fork of mpi-standard
by Pritchard Jr., Howard 24 Feb '21

24 Feb '21

Hi Folks, I think we’ve run over some GitHub private repo limits. Neither Dan nor I can push/pull to/from either our mpiwg-sessions fork of the mpi-standard or forks into our personnel projects spaces. We recently invited another member to our WG sessions Github group and are suspicious we’ve gone over some kind of limit. Wesley could you check this out? At this point I can no longer update my PRs against the mpi-standard since I can’t push to my fork of the mpi-standard. Could others check this? Thanks, Howard -- Howard Pritchard HPC-ENV Los Alamos National Laboratory

1 0

PR 540 -- I/O chapter fixes (started)
by Skjellum, Anthony 23 Feb '21

23 Feb '21

All: This PR reflects discussions (so far) on PR 455 and PR 425. https://github.com/mpi-forum/mpi-standard/pull/540 It will continue to be updated as we work through the rest of the discussion tomorrow. I will be able to make the fixes as we go (I hope) through the rest of the PR 425 and 455 issues tomorrow. Any further points appreciated. Tony Anthony Skjellum, PhD Professor of Computer Science and Chair of Excellence Director, SimCenter University of Tennessee at Chattanooga (UTC) tony-skjellum(a)utc.edu [or skjellum(a)gmail.com] cell: 205-807-4968

1 0

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan
by Wesley Bland 23 Feb '21

23 Feb '21

It seems like Martin covered all of the points I was going to mention. I’d summarize by saying that I believe we’re following the rules as written. I also believe that we’re giving the rules a bit of abuse here because of the volume of changes coming in at the last minute. That being said, I think the volume of changes is actually a good thing. This is the first time we’re ratifying the MPI Standard since moving from SVN to Git/GitHub and doing so has made the process more transparent and easier for people to catch these sorts of small issues that we’re discussing now. All of being at home has potentially also given us more time over the last few months to find each of these issues. I freely expect and admit that I’ve probably missed a PR or two as I’ve been trying to keep up. Hopefully we’ve found them all now (thanks to those who have pointed me to some of those that I missed). If we do end up having another FRM, I agree that it gives us one more opportunity to give the entire document a read-through. I don’t think we’ll do another pass like we did before the December meeting, but we should certainly have the CCs look through it. However, when doing so, remember that we’ll have to accept some level of imperfection. The document has been imperfect for a long time and will continue to be so in the future. We have to look at the list of issues that we know about and decide which ones we can live with and for which ones we’re willing to delay publishing MPI 4.0. It’s especially important to be cognizant of the procedures that we’ve chosen for ourselves when doing this and to avoid making more and more exceptions just to get “one more thing” into the document. Every time someone suggests that we should “just make this change" to improve the text, you should think “just make this change” == “delay MPI 4.0 for another meeting or more”. Thanks, Wes > On Feb 23, 2021, at 4:30 AM, Martin Schulz via mpi-forum <mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: > > Hi Rolf, > > Comments inline marked with ">>" > > Martin > > > -- > Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems > Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching > Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) > Email: schulzm(a)in.tum.de <mailto:[email protected]> > > > > On 23.02.21, 09:53, "mpi-forum on behalf of Rolf Rabenseifner via mpi-forum" <mpi-forum-bounces(a)lists.mpi-forum.org <mailto:[email protected]> on behalf of mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> wrote: > > Dear Wesley and all, > > Wesley, you did yesterday a wonderful job. > Please do not take the following items as any critism on your work. > they are only on procedural/general problems we may have. > > 1. Can it be that one No-No-vote can influence the outcome of the MPI > standard when the majority does not see a problem with the text? > >>> Yes, that is correct - if a No-No fails, then we vote on whether to advance the standard without that PR. > > We may procedurally gave and still give no-no-voters to much > influence on the text. > >>> To some degree, yes, but this is supposed to be a last stop-gap measure and then we do, of course, folks to act reasonable with the consequences, which - so far - has worked IHMO. > > I hope that this > - will not happen during this meeting > >>> To be honest, I wouldn't be surprised if it did, and probably not without reason. > > - and if it happens then I hope that the FRM is changed to a RC > >>> That's why we will have that vote on a different day - when we vote on the whole standard, everyone will have seen what had been voted in and what out and has the ability to vote accordingly. Personally, I hope as well that, if we find problems and we reject additions that are impactful, that a majority would vote for another round for the FRM. > > - and therefore the exactly same PR is then voted with a normal > erata-vote into the standard on the next meeting. > >>> That is technically correct, but I would hope that we can fix issue that are brought up so that the concerns of the few no/no votes are met after the changes. Note that we do not have to fix them this week (would be good if we do, but not required), but we need to add them to the list of fixes needed. So far, from the issues that are noted on the list, I would think that we can achieve agreement on all of them before June. We'll see - I am an eternal optimist __. > > > 2. My aplogies that -- also I was prepared to catch it -- > I oversaw the moment when the folowing text change was presented: > > RC 1 > Example 5.22 An elaborate example. > int position, i; > float a[1000]; > char buff[1000]; > changed in RC 2 > Example 5.22 An elaborate example. > int position, i = 200; > Correct > float a[200]; > Correct > char buff[1000]; /* larger than sizeof(int) + 200 * sizeof(float) */ > Wrong: This sentence should present a sufficient requirement and > not only a maybe necessary requirement (like large than 0) > Correct would have been: > "larger than the sum of the sizes returned from MPI_PACK_SIZE > for 1 MPI_INT and 200 MPI_FLOAT" > >>> Thanks for bringing this up, I added this to the agenda for today > > 2a. The procedural problem is that the presentation of changed files > may be swammed by minor corrections like typos, grammer, formatting, > removed hyphens, index entries, corrections of macro usage, ... > The real text changes may be overseen. > > > 3. Especially for the point-to-point chapter this is really hard. > > May be also for other chapter as seen in item 2. above. > > How to proceed with this problem? > > (Of course without loosing time on irrelevant changes.) > >>> Not sure there is a good way - perhaps we should adjust how we handle this in the future by recommending to bundle only "like" changes in a single PR (only index, only grammar, ...), but for now this is too late. I think we have to rely on everyone looking through the PR and I would also like to see CC chairs to go over their chapter again, especially if we push the FRM by one meeting. > > > 4. It is overseen, if reviews for RC 1 are partially overseen > (or just not implemented). > > https://github.com/mpi-forum/mpi-issues/issues/341 <https://github.com/mpi-forum/mpi-issues/issues/341> > is full of change requests. > Only partially these requests have check boxes, partally not. > And only partially, these check boxes are checked. > > The issue #341 was quietly moved on Jan 19 from 4.0 to 4.1. > > Are there other chapter with outstanding corrections? > > Can we fix it without no-no-votes by reading the required changes > during this meeting and having them as errata votes next meeting? > > How to proceed with this problem? > >>> We did indeed move some items, which were not deemed ready nor critical, to MPI 4.1 (typically as part of one of the virtual meetings, not sure anymore when this happened for this ticket). If you think this was done in error and the changes are critical (as they affect correctness), we should discuss this. > > > 5. Did we oversaw other PRs (like the very old number PR425 > merged very late)? > >>> I have that PR on the list as part of the I/O chapter discussion today. Is there something else missing? > > Best regards > Rolf > > > > > ----- Original Message ----- >> From: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> >> To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> >> Cc: "Wesley Bland" <work(a)wesbland.com <mailto:[email protected]>> >> Sent: Thursday, February 18, 2021 8:58:55 PM >> Subject: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan > >> Hi all, >> >> I wanted to give an update on the plan for the meeting next week after our >> virtual meeting yesterday. >> >> The original plan for the Feb 2021 meeting was to be a Final Ratification >> Meeting (FRM), which would mean that at some point during the meeting, we would >> potentially ratify MPI 4.0 and elect officers for the next release of the MPI >> Standard. The rules for that are in our procedures document on our website and >> it turns out they handle our current situation very well. The relevant pieces >> are this: >> >> >> >> 1. At the last meeting, we made two lists of items that were not yet fixed. >> These lists are maintained on agenda and voting page for the meeting: [ >> https://www.mpi-forum.org/meetings/2021/02/votes <https://www.mpi-forum.org/meetings/2021/02/votes> | >> https://www.mpi-forum.org/meetings/2021/02/votes <https://www.mpi-forum.org/meetings/2021/02/votes> ] >> 2. >> 1. The items that we knew about by the end of the December 2020 meeting - >> Everything on this list that was fixed will be voted on using the same rules as >> an errata vote . >> 2. The items that were discovered after the end of the December 2020 meeting - >> Everything on this list that was fixed will be voted on using the same rules as >> a no-no vote . >> 3. We will construct another list during the February 2021 meeting to keep track >> of remaining issues that we see with the document. This list is in the same >> place as where we tracked the previous work: [ >> https://github.com/mpi-forum/mpi-issues/projects/2 <https://github.com/mpi-forum/mpi-issues/projects/2> | >> https://github.com/mpi-forum/mpi-issues/projects/2 <https://github.com/mpi-forum/mpi-issues/projects/2> ] >> 4. On a separate day from the items in #1 above, we will have a ballot to decide >> whether the remaining issues should cause us to delay ratifying MPI 4.0. >> 5. >> 1. Without attempting to editorialize too much (people may vote in whatever way >> they think is most appropriate), based on the conversations in the virtual >> meeting yesterday, I would expect this ballot to pass. The ramifications of >> that are below. >> 6. If the ballot in #3 fails (saying the list of remaining items is not blocking >> MPI 4.0), then we hold another ballot to ratify MPI 4.0. >> 7. If the ballot in #3 passes (saying the list should block MPI 4.0), then the >> February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) >> like our December 2020 meeting. This means: >> 8. >> 1. The June 2021 meeting becomes the new FRM meeting for MPI 4.0 >> 2. The remaining items list becomes the “errata” list for the June meeting and >> everything remaining on it should be addressed ASAP to allow time to discuss, >> merge, and generate a new release candidate document for that meeting >> (tentative deadline for PRs to be created would be April 19th, but they should >> be created and hopefully merged long before that to avoid similar problems for >> the next meeting). >> 3. Any new items that are discovered before the next meeting can still be added >> to the second list for a no-no vote. >> 4. A new chapter-by-chapter reading is not necessary or required. >> 5. Officer nominations will reopen and we will hold elections at the June >> meeting. >> >> If we do decide to delay MPI 4.0, I don’t think the intention is to “open the >> floodgates” for every small thing we’ve noticed is wrong in the document. As >> Bill has said, we’ll never fix every little thing, so right now let’s focus on >> the major issues that would cause problems and keep doing the rest for MPI 4.1. >> If there are remaining issues from the previous lists that we’d like to >> address, go ahead and create the PR for them and we can make a decision later >> on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful. >> >> In order to get through all of the things above and still have time to discuss >> the remaining technical issues, we’re going to have to be very aggressive in >> our timeline for reading all of the changes since the last meeting. As you can >> see on the votes page, we have 76 issues to be read. In an effort to get those >> done as quickly as possible, Martin and I will be going through the issues/PRs >> and asking for input from others as we go (but avoiding context switching from >> laptop to laptop between each issue). We hope this will give us time to finish >> the entire set of issues on day one or two. >> >> If there are items that begin to have prolonged technical discussion, we will >> take that as a sign that the issue needs more discussion with the relevant >> groups outside of the full-forum meeting time, which is very limited. The >> interested parties should schedule a separate time to have those discussions >> and bring the results back in a future virtual meeting over the next month or >> two. >> >> If you haven’t registered for the meeting for next week, please do so now on the >> logistics page: [ https://www.mpi-forum.org/meetings/2021/02/logistics <https://www.mpi-forum.org/meetings/2021/02/logistics> | >> https://www.mpi-forum.org/meetings/2021/02/logistics <https://www.mpi-forum.org/meetings/2021/02/logistics> ] I’ll be updating the >> attendance page periodically, but keep in mind that the process is manual so it >> doesn’t happen immediately. >> >> That’s all from me for now. I think Martin had some more thoughts about what to >> do with the remaining technical items that he’ll address in another email. >> >> Thanks, >> Wes >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de <mailto:[email protected]> . > 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 <http://www.hlrs.de/people/rabenseifner> . > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum> > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum <https://lists.mpi-forum.org/mailman/listinfo/mpi-forum>

1 0

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan
by Martin Schulz 23 Feb '21

23 Feb '21

Hi Rolf, Comments inline marked with ">>" Martin -- Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de On 23.02.21, 09:53, "mpi-forum on behalf of Rolf Rabenseifner via mpi-forum" <mpi-forum-bounces(a)lists.mpi-forum.org on behalf of mpi-forum(a)lists.mpi-forum.org> wrote: Dear Wesley and all, Wesley, you did yesterday a wonderful job. Please do not take the following items as any critism on your work. they are only on procedural/general problems we may have. 1. Can it be that one No-No-vote can influence the outcome of the MPI standard when the majority does not see a problem with the text? >> Yes, that is correct - if a No-No fails, then we vote on whether to advance the standard without that PR. We may procedurally gave and still give no-no-voters to much influence on the text. >> To some degree, yes, but this is supposed to be a last stop-gap measure and then we do, of course, folks to act reasonable with the consequences, which - so far - has worked IHMO. I hope that this - will not happen during this meeting >> To be honest, I wouldn't be surprised if it did, and probably not without reason. - and if it happens then I hope that the FRM is changed to a RC >> That's why we will have that vote on a different day - when we vote on the whole standard, everyone will have seen what had been voted in and what out and has the ability to vote accordingly. Personally, I hope as well that, if we find problems and we reject additions that are impactful, that a majority would vote for another round for the FRM. - and therefore the exactly same PR is then voted with a normal erata-vote into the standard on the next meeting. >> That is technically correct, but I would hope that we can fix issue that are brought up so that the concerns of the few no/no votes are met after the changes. Note that we do not have to fix them this week (would be good if we do, but not required), but we need to add them to the list of fixes needed. So far, from the issues that are noted on the list, I would think that we can achieve agreement on all of them before June. We'll see - I am an eternal optimist __. 2. My aplogies that -- also I was prepared to catch it -- I oversaw the moment when the folowing text change was presented: RC 1 Example 5.22 An elaborate example. int position, i; float a[1000]; char buff[1000]; changed in RC 2 Example 5.22 An elaborate example. int position, i = 200; Correct float a[200]; Correct char buff[1000]; /* larger than sizeof(int) + 200 * sizeof(float) */ Wrong: This sentence should present a sufficient requirement and not only a maybe necessary requirement (like large than 0) Correct would have been: "larger than the sum of the sizes returned from MPI_PACK_SIZE for 1 MPI_INT and 200 MPI_FLOAT" >> Thanks for bringing this up, I added this to the agenda for today 2a. The procedural problem is that the presentation of changed files may be swammed by minor corrections like typos, grammer, formatting, removed hyphens, index entries, corrections of macro usage, ... The real text changes may be overseen. 3. Especially for the point-to-point chapter this is really hard. May be also for other chapter as seen in item 2. above. How to proceed with this problem? (Of course without loosing time on irrelevant changes.) >> Not sure there is a good way - perhaps we should adjust how we handle this in the future by recommending to bundle only "like" changes in a single PR (only index, only grammar, ...), but for now this is too late. I think we have to rely on everyone looking through the PR and I would also like to see CC chairs to go over their chapter again, especially if we push the FRM by one meeting. 4. It is overseen, if reviews for RC 1 are partially overseen (or just not implemented). https://github.com/mpi-forum/mpi-issues/issues/341 is full of change requests. Only partially these requests have check boxes, partally not. And only partially, these check boxes are checked. The issue #341 was quietly moved on Jan 19 from 4.0 to 4.1. Are there other chapter with outstanding corrections? Can we fix it without no-no-votes by reading the required changes during this meeting and having them as errata votes next meeting? How to proceed with this problem? >> We did indeed move some items, which were not deemed ready nor critical, to MPI 4.1 (typically as part of one of the virtual meetings, not sure anymore when this happened for this ticket). If you think this was done in error and the changes are critical (as they affect correctness), we should discuss this. 5. Did we oversaw other PRs (like the very old number PR425 merged very late)? >> I have that PR on the list as part of the I/O chapter discussion today. Is there something else missing? Best regards Rolf ----- Original Message ----- > From: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Cc: "Wesley Bland" <work(a)wesbland.com> > Sent: Thursday, February 18, 2021 8:58:55 PM > Subject: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan > Hi all, > > I wanted to give an update on the plan for the meeting next week after our > virtual meeting yesterday. > > The original plan for the Feb 2021 meeting was to be a Final Ratification > Meeting (FRM), which would mean that at some point during the meeting, we would > potentially ratify MPI 4.0 and elect officers for the next release of the MPI > Standard. The rules for that are in our procedures document on our website and > it turns out they handle our current situation very well. The relevant pieces > are this: > > > > 1. At the last meeting, we made two lists of items that were not yet fixed. > These lists are maintained on agenda and voting page for the meeting: [ > https://www.mpi-forum.org/meetings/2021/02/votes | > https://www.mpi-forum.org/meetings/2021/02/votes ] > 2. > 1. The items that we knew about by the end of the December 2020 meeting - > Everything on this list that was fixed will be voted on using the same rules as > an errata vote . > 2. The items that were discovered after the end of the December 2020 meeting - > Everything on this list that was fixed will be voted on using the same rules as > a no-no vote . > 3. We will construct another list during the February 2021 meeting to keep track > of remaining issues that we see with the document. This list is in the same > place as where we tracked the previous work: [ > https://github.com/mpi-forum/mpi-issues/projects/2 | > https://github.com/mpi-forum/mpi-issues/projects/2 ] > 4. On a separate day from the items in #1 above, we will have a ballot to decide > whether the remaining issues should cause us to delay ratifying MPI 4.0. > 5. > 1. Without attempting to editorialize too much (people may vote in whatever way > they think is most appropriate), based on the conversations in the virtual > meeting yesterday, I would expect this ballot to pass. The ramifications of > that are below. > 6. If the ballot in #3 fails (saying the list of remaining items is not blocking > MPI 4.0), then we hold another ballot to ratify MPI 4.0. > 7. If the ballot in #3 passes (saying the list should block MPI 4.0), then the > February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) > like our December 2020 meeting. This means: > 8. > 1. The June 2021 meeting becomes the new FRM meeting for MPI 4.0 > 2. The remaining items list becomes the “errata” list for the June meeting and > everything remaining on it should be addressed ASAP to allow time to discuss, > merge, and generate a new release candidate document for that meeting > (tentative deadline for PRs to be created would be April 19th, but they should > be created and hopefully merged long before that to avoid similar problems for > the next meeting). > 3. Any new items that are discovered before the next meeting can still be added > to the second list for a no-no vote. > 4. A new chapter-by-chapter reading is not necessary or required. > 5. Officer nominations will reopen and we will hold elections at the June > meeting. > > If we do decide to delay MPI 4.0, I don’t think the intention is to “open the > floodgates” for every small thing we’ve noticed is wrong in the document. As > Bill has said, we’ll never fix every little thing, so right now let’s focus on > the major issues that would cause problems and keep doing the rest for MPI 4.1. > If there are remaining issues from the previous lists that we’d like to > address, go ahead and create the PR for them and we can make a decision later > on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful. > > In order to get through all of the things above and still have time to discuss > the remaining technical issues, we’re going to have to be very aggressive in > our timeline for reading all of the changes since the last meeting. As you can > see on the votes page, we have 76 issues to be read. In an effort to get those > done as quickly as possible, Martin and I will be going through the issues/PRs > and asking for input from others as we go (but avoiding context switching from > laptop to laptop between each issue). We hope this will give us time to finish > the entire set of issues on day one or two. > > If there are items that begin to have prolonged technical discussion, we will > take that as a sign that the issue needs more discussion with the relevant > groups outside of the full-forum meeting time, which is very limited. The > interested parties should schedule a separate time to have those discussions > and bring the results back in a future virtual meeting over the next month or > two. > > If you haven’t registered for the meeting for next week, please do so now on the > logistics page: [ https://www.mpi-forum.org/meetings/2021/02/logistics | > https://www.mpi-forum.org/meetings/2021/02/logistics ] I’ll be updating the > attendance page periodically, but keep in mind that the process is manual so it > doesn’t happen immediately. > > That’s all from me for now. I think Martin had some more thoughts about what to > do with the remaining technical items that he’ll address in another email. > > Thanks, > Wes > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/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: Room 1.307) . _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan
by Rolf Rabenseifner 23 Feb '21

23 Feb '21

Dear Wesley and all, Wesley, you did yesterday a wonderful job. Please do not take the following items as any critism on your work. they are only on procedural/general problems we may have. 1. Can it be that one No-No-vote can influence the outcome of the MPI standard when the majority does not see a problem with the text? We may procedurally gave and still give no-no-voters to much influence on the text. I hope that this - will not happen during this meeting - and if it happens then I hope that the FRM is changed to a RC - and therefore the exactly same PR is then voted with a normal erata-vote into the standard on the next meeting. 2. My aplogies that -- also I was prepared to catch it -- I oversaw the moment when the folowing text change was presented: RC 1 Example 5.22 An elaborate example. int position, i; float a[1000]; char buff[1000]; changed in RC 2 Example 5.22 An elaborate example. int position, i = 200; Correct float a[200]; Correct char buff[1000]; /* larger than sizeof(int) + 200 * sizeof(float) */ Wrong: This sentence should present a sufficient requirement and not only a maybe necessary requirement (like large than 0) Correct would have been: "larger than the sum of the sizes returned from MPI_PACK_SIZE for 1 MPI_INT and 200 MPI_FLOAT" 2a. The procedural problem is that the presentation of changed files may be swammed by minor corrections like typos, grammer, formatting, removed hyphens, index entries, corrections of macro usage, ... The real text changes may be overseen. 3. Especially for the point-to-point chapter this is really hard. May be also for other chapter as seen in item 2. above. How to proceed with this problem? (Of course without loosing time on irrelevant changes.) 4. It is overseen, if reviews for RC 1 are partially overseen (or just not implemented). https://github.com/mpi-forum/mpi-issues/issues/341 is full of change requests. Only partially these requests have check boxes, partally not. And only partially, these check boxes are checked. The issue #341 was quietly moved on Jan 19 from 4.0 to 4.1. Are there other chapter with outstanding corrections? Can we fix it without no-no-votes by reading the required changes during this meeting and having them as errata votes next meeting? How to proceed with this problem? 5. Did we oversaw other PRs (like the very old number PR425 merged very late)? Best regards Rolf ----- Original Message ----- > From: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Cc: "Wesley Bland" <work(a)wesbland.com> > Sent: Thursday, February 18, 2021 8:58:55 PM > Subject: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan > Hi all, > > I wanted to give an update on the plan for the meeting next week after our > virtual meeting yesterday. > > The original plan for the Feb 2021 meeting was to be a Final Ratification > Meeting (FRM), which would mean that at some point during the meeting, we would > potentially ratify MPI 4.0 and elect officers for the next release of the MPI > Standard. The rules for that are in our procedures document on our website and > it turns out they handle our current situation very well. The relevant pieces > are this: > > > > 1. At the last meeting, we made two lists of items that were not yet fixed. > These lists are maintained on agenda and voting page for the meeting: [ > https://www.mpi-forum.org/meetings/2021/02/votes | > https://www.mpi-forum.org/meetings/2021/02/votes ] > 2. > 1. The items that we knew about by the end of the December 2020 meeting - > Everything on this list that was fixed will be voted on using the same rules as > an errata vote . > 2. The items that were discovered after the end of the December 2020 meeting - > Everything on this list that was fixed will be voted on using the same rules as > a no-no vote . > 3. We will construct another list during the February 2021 meeting to keep track > of remaining issues that we see with the document. This list is in the same > place as where we tracked the previous work: [ > https://github.com/mpi-forum/mpi-issues/projects/2 | > https://github.com/mpi-forum/mpi-issues/projects/2 ] > 4. On a separate day from the items in #1 above, we will have a ballot to decide > whether the remaining issues should cause us to delay ratifying MPI 4.0. > 5. > 1. Without attempting to editorialize too much (people may vote in whatever way > they think is most appropriate), based on the conversations in the virtual > meeting yesterday, I would expect this ballot to pass. The ramifications of > that are below. > 6. If the ballot in #3 fails (saying the list of remaining items is not blocking > MPI 4.0), then we hold another ballot to ratify MPI 4.0. > 7. If the ballot in #3 passes (saying the list should block MPI 4.0), then the > February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) > like our December 2020 meeting. This means: > 8. > 1. The June 2021 meeting becomes the new FRM meeting for MPI 4.0 > 2. The remaining items list becomes the “errata” list for the June meeting and > everything remaining on it should be addressed ASAP to allow time to discuss, > merge, and generate a new release candidate document for that meeting > (tentative deadline for PRs to be created would be April 19th, but they should > be created and hopefully merged long before that to avoid similar problems for > the next meeting). > 3. Any new items that are discovered before the next meeting can still be added > to the second list for a no-no vote. > 4. A new chapter-by-chapter reading is not necessary or required. > 5. Officer nominations will reopen and we will hold elections at the June > meeting. > > If we do decide to delay MPI 4.0, I don’t think the intention is to “open the > floodgates” for every small thing we’ve noticed is wrong in the document. As > Bill has said, we’ll never fix every little thing, so right now let’s focus on > the major issues that would cause problems and keep doing the rest for MPI 4.1. > If there are remaining issues from the previous lists that we’d like to > address, go ahead and create the PR for them and we can make a decision later > on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful. > > In order to get through all of the things above and still have time to discuss > the remaining technical issues, we’re going to have to be very aggressive in > our timeline for reading all of the changes since the last meeting. As you can > see on the votes page, we have 76 issues to be read. In an effort to get those > done as quickly as possible, Martin and I will be going through the issues/PRs > and asking for input from others as we go (but avoiding context switching from > laptop to laptop between each issue). We hope this will give us time to finish > the entire set of issues on day one or two. > > If there are items that begin to have prolonged technical discussion, we will > take that as a sign that the issue needs more discussion with the relevant > groups outside of the full-forum meeting time, which is very limited. The > interested parties should schedule a separate time to have those discussions > and bring the results back in a future virtual meeting over the next month or > two. > > If you haven’t registered for the meeting for next week, please do so now on the > logistics page: [ https://www.mpi-forum.org/meetings/2021/02/logistics | > https://www.mpi-forum.org/meetings/2021/02/logistics ] I’ll be updating the > attendance page periodically, but keep in mind that the process is manual so it > doesn’t happen immediately. > > That’s all from me for now. I think Martin had some more thoughts about what to > do with the remaining technical items that he’ll address in another email. > > Thanks, > Wes > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/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: Room 1.307) .

1 0

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan
by Guillaume Mercier 22 Feb '21

22 Feb '21

Hi Martin, Just tio let you know: I won't be available for the meetings during the first hour or so. I'll attend after that. So, anything related to chapter 7 should be handled from 5pm unless it's straightforward and does not require my presence. Best Guillaume On 2/22/21 6:57 AM, Martin Schulz via mpi-forum wrote: > Hi all, > > > > Thanks to Wesley for putting together this detailed description of the > meeting this week. I hope this helps lay out what’s the plan for the > quite packed meeting this week, Let me reiterate a few items, though: > > > > * If you haven’t done so, please register for the meeting (important > for voting eligibility!) > > > > * We have a long list of items to go through and to be voted on and we > would like to get this number down as quickly as possible, so that > we get to a stable base again. As Wesley said, the plan is to start > today with going through this list quickly and we would therefore > ask everyone to look at the list beforehand and to avoid long > discussions. This should not mean that you have to agree with > everything – if there is larger concern, please raise it (no need to > hold back, we want to find problems) and we’ll flag the issue and > discuss it later (in the meeting if time allows or in a virtual > meeting). This way we can get all non-controversial issue out of the > way and reduce the total number of issues to deal with. > > > > * As for delaying MPI 4.0 – as Wesley said, everyone should vote as > they/their organization sees fit, but based on the conversations in > the last meetings there are issues currently that are worth being > concerned about. Personally I think, delaying by one meeting to get > such larger items fixed (especially where bindings are affected) is > worth considering (which would still allow us to release MPI 4.0 for > ISC), but we should limit this to these larger items only and not > try address other items or even to add functionality. > > > > * However, having said that – should we decide to delay MPI 4.0 and if > there are existing known errata items (especially non-controversial > ones) that may make sense to include (without causing any further > delay), please let us know. > > > > * As for the larger items that need to be discussed – I have added > them to the agenda. We will go through them after our initial pass > of the existing issues (as described above). From what I have seen, > there are concrete proposals on the table for each and we will do a > preliminary reading and discussion on those. If needed, we will have > additional virtual meetings on them – it would be good, though, to > get agreement on the possible solution rather sooner than later, to > give chapter authors to check for potential side effects and > unintended impacts. > > > > * As Wesley said, our rules do not require another page by page review > of the entire document. However, we have seen extensive changes > throughout the document as part of our last review and hence chapter > committee chairs (along with their committees, if needed) should go > through their chapters and verify that changes had no unintended > impact. > > > > * With all the readings and votes on the MPI 4.0 changes, please don’t > forget we’ll also have second vote on the side document containing > the summary of the semantics of all operation-related MPI procedures > > > > I hope this gives even more background on the planned procedures – if > there are any open questions or suggestions, please bring them up at the > beginning of the meeting! > > > > Talk to you all in a few hours, > > Thanks, > > > > Martin > > > > > > -- > Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems > Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching > Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) > Email: schulzm(a)in.tum.de > > > > > > > > *From: *mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of > Wesley Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> > *Reply-To: *Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> > *Date: *Thursday, 18. February 2021 at 21:00 > *To: *MPI Forum <mpi-forum(a)lists.mpi-forum.org> > *Cc: *Wesley Bland <work(a)wesbland.com> > *Subject: *[Mpi-forum] Feb 2021 MPI Forum Meeting Plan > > > > Hi all, > > > > I wanted to give an update on the plan for the meeting next week after > our virtual meeting yesterday. > > > > The original plan for the Feb 2021 meeting was to be a Final > Ratification Meeting (FRM), which would mean that at some point during > the meeting, we would potentially ratify MPI 4.0 and elect officers for > the next release of the MPI Standard. The rules for that are in our > procedures document on our website and it turns out they handle our > current situation very well. The relevant pieces are this: > > > > 1. At the last meeting, we made two lists of items that were not yet > fixed. These lists are maintained on agenda and voting page for the > meeting: https://www.mpi-forum.org/meetings/2021/02/votes > > 1. The items that we knew about by the end of the December 2020 > meeting - Everything on this list that was fixed will be voted > on using the same rules as an *errata vote*. > 2. The items that were discovered after the end of the December > 2020 meeting - Everything on this list that was fixed will be > voted on using the same rules as a *no-no vote*. > > 2. We will construct another list during the February 2021 meeting to > keep track of remaining issues that we see with the document. This > list is in the same place as where we tracked the previous > work: https://github.com/mpi-forum/mpi-issues/projects/2 > 3. On a separate day from the items in #1 above, we will have a ballot > to decide whether the remaining issues should cause us to delay > ratifying MPI 4.0. > > 1. Without attempting to editorialize too much (people may vote in > whatever way they think is most appropriate), based on the > conversations in the virtual meeting yesterday, I would expect > this ballot to pass. The ramifications of that are below. > > 4. If the ballot in #3 *fails* (saying the list of remaining items is > not blocking MPI 4.0), then we hold another ballot to ratify MPI 4.0. > 5. If the ballot in #3 *passes* (saying the list should block MPI 4.0), > then the February 2021 meeting essentially becomes a Release > Candidate Meeting (RCM) like our December 2020 meeting. This means: > > 1. The June 2021 meeting becomes the new FRM meeting for MPI 4.0 > 2. The remaining items list becomes the “errata” list for the June > meeting and everything remaining on it should be addressed ASAP > to allow time to discuss, merge, and generate a new release > candidate document for that meeting (tentative deadline for PRs > to be created would be April 19th, but they should be created > and hopefully merged long before that to avoid similar problems > for the next meeting). > 3. Any new items that are discovered before the next meeting can > still be added to the second list for a no-no vote. > 4. A new chapter-by-chapter reading is not necessary or required. > 5. Officer nominations will reopen and we will hold elections at > the June meeting. > > > > If we do decide to delay MPI 4.0, I don’t think the intention is to > “open the floodgates” for every small thing we’ve noticed is wrong in > the document. As Bill has said, we’ll never fix every little thing, so > right now let’s focus on the major issues that would cause problems and > keep doing the rest for MPI 4.1. If there are remaining issues from the > previous lists that we’d like to address, go ahead and create the PR for > them and we can make a decision later on whether to vote it into MPI 4.0 > or 4.1. Either way, the PR will be useful. > > > > In order to get through all of the things above and still have time to > discuss the remaining technical issues, we’re going to have to be very > aggressive in our timeline for reading all of the changes since the last > meeting. As you can see on the votes page, we have 76 issues to be read. > In an effort to get those done as quickly as possible, Martin and I will > be going through the issues/PRs and asking for input from others as we > go (but avoiding context switching from laptop to laptop between each > issue). We hope this will give us time to finish the entire set of > issues on day one or two. > > > > If there are items that begin to have prolonged technical discussion, we > will take that as a sign that the issue needs more discussion with the > relevant groups outside of the full-forum meeting time, which is very > limited. The interested parties should schedule a separate time to have > those discussions and bring the results back in a future virtual meeting > over the next month or two. > > > > If you haven’t registered for the meeting for next week, please do so > now on the logistics > page: https://www.mpi-forum.org/meetings/2021/02/logistics I’ll be > updating the attendance page periodically, but keep in mind that the > process is manual so it doesn’t happen immediately. > > > > That’s all from me for now. I think Martin had some more thoughts about > what to do with the remaining technical items that he’ll address in > another email. > > > > Thanks, > > Wes > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >

1 0

Re: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan
by Martin Schulz 21 Feb '21

21 Feb '21

Hi all, Thanks to Wesley for putting together this detailed description of the meeting this week. I hope this helps lay out what’s the plan for the quite packed meeting this week, Let me reiterate a few items, though: If you haven’t done so, please register for the meeting (important for voting eligibility!) We have a long list of items to go through and to be voted on and we would like to get this number down as quickly as possible, so that we get to a stable base again. As Wesley said, the plan is to start today with going through this list quickly and we would therefore ask everyone to look at the list beforehand and to avoid long discussions. This should not mean that you have to agree with everything – if there is larger concern, please raise it (no need to hold back, we want to find problems) and we’ll flag the issue and discuss it later (in the meeting if time allows or in a virtual meeting). This way we can get all non-controversial issue out of the way and reduce the total number of issues to deal with. As for delaying MPI 4.0 – as Wesley said, everyone should vote as they/their organization sees fit, but based on the conversations in the last meetings there are issues currently that are worth being concerned about. Personally I think, delaying by one meeting to get such larger items fixed (especially where bindings are affected) is worth considering (which would still allow us to release MPI 4.0 for ISC), but we should limit this to these larger items only and not try address other items or even to add functionality. However, having said that – should we decide to delay MPI 4.0 and if there are existing known errata items (especially non-controversial ones) that may make sense to include (without causing any further delay), please let us know. As for the larger items that need to be discussed – I have added them to the agenda. We will go through them after our initial pass of the existing issues (as described above). From what I have seen, there are concrete proposals on the table for each and we will do a preliminary reading and discussion on those. If needed, we will have additional virtual meetings on them – it would be good, though, to get agreement on the possible solution rather sooner than later, to give chapter authors to check for potential side effects and unintended impacts. As Wesley said, our rules do not require another page by page review of the entire document. However, we have seen extensive changes throughout the document as part of our last review and hence chapter committee chairs (along with their committees, if needed) should go through their chapters and verify that changes had no unintended impact. With all the readings and votes on the MPI 4.0 changes, please don’t forget we’ll also have second vote on the side document containing the summary of the semantics of all operation-related MPI procedures I hope this gives even more background on the planned procedures – if there are any open questions or suggestions, please bring them up at the beginning of the meeting! Talk to you all in a few hours, Thanks, Martin -- Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> on behalf of Wesley Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> Reply-To: Main MPI Forum mailing list <mpi-forum(a)lists.mpi-forum.org> Date: Thursday, 18. February 2021 at 21:00 To: MPI Forum <mpi-forum(a)lists.mpi-forum.org> Cc: Wesley Bland <work(a)wesbland.com> Subject: [Mpi-forum] Feb 2021 MPI Forum Meeting Plan Hi all, I wanted to give an update on the plan for the meeting next week after our virtual meeting yesterday. The original plan for the Feb 2021 meeting was to be a Final Ratification Meeting (FRM), which would mean that at some point during the meeting, we would potentially ratify MPI 4.0 and elect officers for the next release of the MPI Standard. The rules for that are in our procedures document on our website and it turns out they handle our current situation very well. The relevant pieces are this: At the last meeting, we made two lists of items that were not yet fixed. These lists are maintained on agenda and voting page for the meeting: https://www.mpi-forum.org/meetings/2021/02/votes The items that we knew about by the end of the December 2020 meeting - Everything on this list that was fixed will be voted on using the same rules as an errata vote. The items that were discovered after the end of the December 2020 meeting - Everything on this list that was fixed will be voted on using the same rules as a no-no vote. We will construct another list during the February 2021 meeting to keep track of remaining issues that we see with the document. This list is in the same place as where we tracked the previous work: https://github.com/mpi-forum/mpi-issues/projects/2 On a separate day from the items in #1 above, we will have a ballot to decide whether the remaining issues should cause us to delay ratifying MPI 4.0. Without attempting to editorialize too much (people may vote in whatever way they think is most appropriate), based on the conversations in the virtual meeting yesterday, I would expect this ballot to pass. The ramifications of that are below. If the ballot in #3 fails (saying the list of remaining items is not blocking MPI 4.0), then we hold another ballot to ratify MPI 4.0. If the ballot in #3 passes (saying the list should block MPI 4.0), then the February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) like our December 2020 meeting. This means: The June 2021 meeting becomes the new FRM meeting for MPI 4.0 The remaining items list becomes the “errata” list for the June meeting and everything remaining on it should be addressed ASAP to allow time to discuss, merge, and generate a new release candidate document for that meeting (tentative deadline for PRs to be created would be April 19th, but they should be created and hopefully merged long before that to avoid similar problems for the next meeting). Any new items that are discovered before the next meeting can still be added to the second list for a no-no vote. A new chapter-by-chapter reading is not necessary or required. Officer nominations will reopen and we will hold elections at the June meeting. If we do decide to delay MPI 4.0, I don’t think the intention is to “open the floodgates” for every small thing we’ve noticed is wrong in the document. As Bill has said, we’ll never fix every little thing, so right now let’s focus on the major issues that would cause problems and keep doing the rest for MPI 4.1. If there are remaining issues from the previous lists that we’d like to address, go ahead and create the PR for them and we can make a decision later on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful. In order to get through all of the things above and still have time to discuss the remaining technical issues, we’re going to have to be very aggressive in our timeline for reading all of the changes since the last meeting. As you can see on the votes page, we have 76 issues to be read. In an effort to get those done as quickly as possible, Martin and I will be going through the issues/PRs and asking for input from others as we go (but avoiding context switching from laptop to laptop between each issue). We hope this will give us time to finish the entire set of issues on day one or two. If there are items that begin to have prolonged technical discussion, we will take that as a sign that the issue needs more discussion with the relevant groups outside of the full-forum meeting time, which is very limited. The interested parties should schedule a separate time to have those discussions and bring the results back in a future virtual meeting over the next month or two. If you haven’t registered for the meeting for next week, please do so now on the logistics page: https://www.mpi-forum.org/meetings/2021/02/logistics I’ll be updating the attendance page periodically, but keep in mind that the process is manual so it doesn’t happen immediately. That’s all from me for now. I think Martin had some more thoughts about what to do with the remaining technical items that he’ll address in another email. Thanks, Wes

1 0

Feb 2021 MPI Forum Meeting Plan
by Wesley Bland 18 Feb '21

18 Feb '21

Hi all, I wanted to give an update on the plan for the meeting next week after our virtual meeting yesterday. The original plan for the Feb 2021 meeting was to be a Final Ratification Meeting (FRM), which would mean that at some point during the meeting, we would potentially ratify MPI 4.0 and elect officers for the next release of the MPI Standard. The rules for that are in our procedures document on our website and it turns out they handle our current situation very well. The relevant pieces are this: At the last meeting, we made two lists of items that were not yet fixed. These lists are maintained on agenda and voting page for the meeting: https://www.mpi-forum.org/meetings/2021/02/votes <https://www.mpi-forum.org/meetings/2021/02/votes> The items that we knew about by the end of the December 2020 meeting - Everything on this list that was fixed will be voted on using the same rules as an errata vote. The items that were discovered after the end of the December 2020 meeting - Everything on this list that was fixed will be voted on using the same rules as a no-no vote. We will construct another list during the February 2021 meeting to keep track of remaining issues that we see with the document. This list is in the same place as where we tracked the previous work: https://github.com/mpi-forum/mpi-issues/projects/2 <https://github.com/mpi-forum/mpi-issues/projects/2> On a separate day from the items in #1 above, we will have a ballot to decide whether the remaining issues should cause us to delay ratifying MPI 4.0. Without attempting to editorialize too much (people may vote in whatever way they think is most appropriate), based on the conversations in the virtual meeting yesterday, I would expect this ballot to pass. The ramifications of that are below. If the ballot in #3 fails (saying the list of remaining items is not blocking MPI 4.0), then we hold another ballot to ratify MPI 4.0. If the ballot in #3 passes (saying the list should block MPI 4.0), then the February 2021 meeting essentially becomes a Release Candidate Meeting (RCM) like our December 2020 meeting. This means: The June 2021 meeting becomes the new FRM meeting for MPI 4.0 The remaining items list becomes the “errata” list for the June meeting and everything remaining on it should be addressed ASAP to allow time to discuss, merge, and generate a new release candidate document for that meeting (tentative deadline for PRs to be created would be April 19th, but they should be created and hopefully merged long before that to avoid similar problems for the next meeting). Any new items that are discovered before the next meeting can still be added to the second list for a no-no vote. A new chapter-by-chapter reading is not necessary or required. Officer nominations will reopen and we will hold elections at the June meeting. If we do decide to delay MPI 4.0, I don’t think the intention is to “open the floodgates” for every small thing we’ve noticed is wrong in the document. As Bill has said, we’ll never fix every little thing, so right now let’s focus on the major issues that would cause problems and keep doing the rest for MPI 4.1. If there are remaining issues from the previous lists that we’d like to address, go ahead and create the PR for them and we can make a decision later on whether to vote it into MPI 4.0 or 4.1. Either way, the PR will be useful. In order to get through all of the things above and still have time to discuss the remaining technical issues, we’re going to have to be very aggressive in our timeline for reading all of the changes since the last meeting. As you can see on the votes page, we have 76 issues to be read. In an effort to get those done as quickly as possible, Martin and I will be going through the issues/PRs and asking for input from others as we go (but avoiding context switching from laptop to laptop between each issue). We hope this will give us time to finish the entire set of issues on day one or two. If there are items that begin to have prolonged technical discussion, we will take that as a sign that the issue needs more discussion with the relevant groups outside of the full-forum meeting time, which is very limited. The interested parties should schedule a separate time to have those discussions and bring the results back in a future virtual meeting over the next month or two. If you haven’t registered for the meeting for next week, please do so now on the logistics page: https://www.mpi-forum.org/meetings/2021/02/logistics <https://www.mpi-forum.org/meetings/2021/02/logistics> I’ll be updating the attendance page periodically, but keep in mind that the process is manual so it doesn’t happen immediately. That’s all from me for now. I think Martin had some more thoughts about what to do with the remaining technical items that he’ll address in another email. Thanks, Wes

1 0