Notes from the March 9-10 MPI/RT meeting in Atlanta.

Reviewed the updated document.  DRAFT is removed from the cover.
The technical editor recommended changes (e.g., to put in common voice)
but all changes were actually made by MPI/RT editors (Yogi).
The standard, having already been voted on, is complete.

We discussed priorities for 1.1 with several folks expressing the desire
that, given the current lack of experience with 1.0, we should stick to
straightforward subjects that can be handled within a year or so.

The prioritized list:
   0. errata
   0.1 wait/sleep proposals which have already been voted in except
       for exact wording
   1. errors
   1.5 an as yet unwritten proposal to get the two 32-bit parts from
       a 64-bit time
   2.  relaxed buffer sizes and offsets
   3.  container (a) iterators and (b) operations
   4.  additional collective operations

Not making the recommended list for 1.1:
   half channels
   K-slack channels
   generalized mode changes
   data reorg capabilities

Discussion of pattern (nee helper) functions: Whether they will be part
of the standard or separate.  Since we didn't have minutes from the
December meeting (why not!) this discussion was (in my opinion) not
conclusive.

Discussion of error proposal: This included how to incorporate it
in the document: a table at the end of the chapter or do all the error
returns need to be discussed in the function text.  Three returns were
renamed:
   MPIRT_ERR_INITIALIZED to MPIRT_ERR_NOT_INITIALIZED (for the case when
     a function is called before the library is initialized)
   MPIRT_ERR_COMMITTED_OBJECT to MPIRT_ERR_OBJECT_COMMITTED for consistency,
     the old name will not change but become deprecated
   MPIRT_ERR_ERRONEOUS_CALL to MPIRT_ERR_UNDEF_FOR_OBJECT
Action items:
   * draft wording for chapter 2, etc. [Dennis]
   * prototype a function/error return table [Yogi]
   * post updated proposal and get straw vote for support [Dennis]

Discussion of variable buffers proposal: There were some minor changes and
one significant one: when receiving a buffer of variable count or offset,
both the actual count and actual offset will be set by the system.  This
allows the reuse of a buffer without manually resetting its offset.

Discussion of the container iterators proposal: In addition to some wording
changes, and the note that the GET/SET_CONTAINER functions are missing,
it was decided that duplicating an iterator also duplicates the current
position so that the two iterators are indistinguishable after the DUP.
This is so that a copy of an iterator can be made at the current point in
the iteration and returned to later.
Action items:
   * send your notes to Nathan [all]
   * rewrite and resubmit [Nathan]

This led to a discussion of whether a DUP of an object gets you a copy
of the parameters at that moment, or the parameters as they were when
the DUPed object was originally created.  Several felt the document said
the latter, while the consensus was that the former was intended -- or
at least wanted now.  Changes will be made to clarify this and included
in the errata.
Action item:
   * write up the errata [Tony]

Another errata item noted: all figures (and tables?) should have numbers,
and there should be a Table of Figures.
Action item:
   * write up the errata [Tony]

Discussion of container operations: The difference between regular and
atomic version of all were revisited.  The result was that the proposal
would be revised as follows:
   there will be a single version of the call for each (remove the atomic
     definitions)
   the order of operation is determined by whether the container is a
     vector or set: if vector, user specifies; if set, implementation specs.
   activate, raise, and start: order means getting the buffer from the
     bufiter and enqueing; QOS determines subsequent execution
   deactivate: order means wait for each to finish in order (note that
     deactivate is essentially a blocking call)
Action item:
   * rewrite and resubmit [Dennis]

Discussion of additional collective channels: Only the important cases should
be addresses to avoid delving into Data Reorg issues which will be a separate
proposal one of these days.  The most important cases are
   all to all clique
   all to all bipartite
   exclusive scatter (sender doesn't receive any)
   exclusive gather (receiver doesn't send any)
The last two are special cases of the second.  In the interest of minimal
additions and short time, it was decided to do the first two cases with some
restrictions: the two groups must be disjoint, and (like current gather and
scatter) the parts have to be evenly divisible by N processors.
Action item:
   * write up a proposal [Arkady]

New proposal wanted to retrieve the current buffer count and list from a
buffer iterator. [Action: Cui]