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: schu...@in.tum.de > > > > > > > > *From: *mpi-forum <mpi-forum-boun...@lists.mpi-forum.org> on behalf of > Wesley Bland via mpi-forum <mpi-forum@lists.mpi-forum.org> > *Reply-To: *Main MPI Forum mailing list <mpi-forum@lists.mpi-forum.org> > *Date: *Thursday, 18. February 2021 at 21:00 > *To: *MPI Forum <mpi-forum@lists.mpi-forum.org> > *Cc: *Wesley Bland <w...@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@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum