[Mpi-forum] Deadline for next year's release

Torsten Hoefler htor at cs.indiana.edu
Wed Sep 2 10:21:25 CDT 2009

Bronis, all,
> Re:
> > Note to everyone who is not in the Helsinki meeting: there was
> > consensus that we want some kind of release in November 2010.  The
> > exact name of that release is still TBD (likely "3.0", but there's
> > still some discussion about this), but the point is that WG's need to
> > have text ready for 1st readings by the ***MARCH 2010*** Forum meeting
> > in order to be included in the Nov 2010 release.
> >
> > This is not too far away.
> No, it is not. It does not seem realistic to me. We
> would clearly have the nonblocking collectives ready
> but I don't think much else would be. I think we could
> have a LITTLE of the tools stuff ready. From what I
> have seen, I doubt other WGs will get beyond that...
we talked about a staged release, possibly also MPI 2.3. I don't think
that we rush anything. I'm positive that the FT group could have a
proposal for consistent error codes and smaller things that are very
important for FT by this time. Other groups like the Hybrid WG could
also have something.

And even if we don't have anything, what can you say against releasing a
smaller incremental version with just NBCs and minor things. 

There was an objection that doing another MPI 2.2-like effort would cost
a lot of the MPI 3 energy. While I fully agree to this, I'd say that
this seems to be a question of policy. We decide what we discuss (and we
should have a good clean base now).

I would also like to have NBCs in an MPI release that does *not* break
API compatibility. The burden on the user who wants to use NBC would be
too big (imagine that you had to rewrite your 10^6 SLOC MPI program to
run with MPI 3.0 just because you want to use NBCs). A good example for
such an API breaker is the necessary MPI_Count discussion. 

A staged release would also ensure easy implementation and the timely
availability of the compliant MPI implementations (I suspect that we
will see MPI 2.2 adoption rather soon).

I am really against rush here, we have to evaluate every new proposal as
rigorously as we evaluated NBCs. If a proposal fails the March
"deadline", then it will simply float into the next release.

All the Best,

 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler       | Postdoctoral Fellow
Open Systems Lab      | Indiana University    
150 S. Woodlawn Ave.  | Bloomington, IN, 474045, USA
Lindley Hall Room 135 | +01 (812) 855-3608

More information about the mpi-forum mailing list