[Mpi-forum] Feb 2021 MPI Forum Meeting Plan

Tue Feb 23 02:52:21 CST 2021

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 at lists.mpi-forum.org>
> To: "Main MPI Forum mailing list" <mpi-forum at lists.mpi-forum.org>
> Cc: "Wesley Bland" <work at 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 at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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) .