[Mpi-forum] Feb 2021 MPI Forum Meeting Plan
Guillaume Mercier
guillaume.mercier at u-bordeaux.fr
Mon Feb 22 01:50:26 CST 2021
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 at in.tum.de
>
>
>
>
>
>
>
> *From: *mpi-forum <mpi-forum-bounces at lists.mpi-forum.org> on behalf of
> Wesley Bland via mpi-forum <mpi-forum at lists.mpi-forum.org>
> *Reply-To: *Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
> *Date: *Thursday, 18. February 2021 at 21:00
> *To: *MPI Forum <mpi-forum at lists.mpi-forum.org>
> *Cc: *Wesley Bland <work at 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 at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20210222/04c0f0a2/attachment.sig>
More information about the mpi-forum
mailing list