[Mpi3-rma] Updated MPI-3 RMA proposal 1
balaji at mcs.anl.gov
Sun Jun 20 15:08:37 CDT 2010
Are you planning to have an actual vote on proposal 1 without a straw
vote? What if the working group missed some detail and the Forum catches
it and rejects the entire proposal?
I'm aware that we initially planned to group items that will likely not
be contended into proposal 1 -- I was in the group that made that
decision. However, we are dropping even related items on the grounds
that it might be contentious. For example, splitting flush/flushall and
allflushall. I'm arguing that this doesn't make sense anymore, so we
need some changes here.
On 06/19/2010 07:37 PM, Torsten Hoefler wrote:
> On Sat, Jun 19, 2010 at 05:52:22PM -0500, Pavan Balaji wrote:
>> On 06/17/2010 01:14 PM, Torsten Hoefler wrote:
>>> Brian has a good point. Proposal 1 was supposed to be the uncontentious
>>> one. We have made the decision to include it in absence of the two main
>>> opponents. Pushing this forward feels incorrect, thus, I removed it for
>>> now from the proposal.
>> This was exactly what I was arguing against -- the break up of the
>> proposals is increasingly becoming as contentious vs. uncontentious. It
>> should be "related items" based instead. And, no, "these are the minimum
>> set of things I need" is not a good definition of related items, as
>> that's a very subjective definition.
> I am pretty sure that the original definition of Proposal 1 was along
> the lines of "uncontentious things that we need for sure". They were
> somewhat unrelated from the beginning (e.g., CAS, Get_accumulate, and
> changing erroneous to undefined don't seem related to me).
> I am in favor of allflushall, however, I find the split into contentious
> and non-contentious reasonable as long as semantics are not split
> between two proposals. In this particular case, proposal 1 would be
> useful without allflushall.
>> Why are we so afraid of adding items that we feel the Forum will not
>> like? It's easy enough to get a straw vote and drop something before the
>> final vote.
> Well, if we stick to the original definition of proposal 1, then there
> should be no straw votes about the content whatsoever. Are you
> advocating to change this definition? I'm fine with a change as long as
> there is some reasonable definition.
>> Second call to Bill/Rajeev -- we need some changes here.
> A policy would really help. But I am not sure what to advocate.
> All the Best,
More information about the mpiwg-rma