+1 for me! On May 29, 2014, at 7:26 AM, Thomas Naughton <naught...@ornl.gov> wrote:
> Hi, > > Thanks Jeff, I think that was a pretty good summary of things. > >> Thomas indicated there was no rush on the RFC; perhaps we can discuss this >> next-next-Tuesday (June 10)? > > Phone discussion seems like a good idea and June 10 sounds good to me. > > Thanks, > --tjn > > _________________________________________________________________________ > Thomas Naughton naught...@ornl.gov > Research Associate (865) 576-4184 > > > On Thu, 29 May 2014, Jeff Squyres (jsquyres) wrote: > >> I refrained from speaking up on this thread because I was on travel, and I >> wanted to think a bit more about this before I said anything. >> >> Let me try to summarize the arguments that have been made so far... >> >> A. Things people seem to agree on: >> >> 1. Inclusion in trunk has no correlation to being included in a release >> 2. Prior examples of (effectively) single-organization components >> >> B. Reasons to have STCI/HPX/etc. components in SVN trunk: >> >> 1. Multiple organizations are asking (ORNL, UTK, UH) >> 2. Easier to develop/merge the STCI/HPX/etc. components over time >> 3. Find all alternate RTE components in one place (vs. multiple internet >> repos) >> 4. More examples of how to use the RTE framework >> >> C. Reasons not to have STCI/HPX/etc. components in the SVN trunk: >> >> 1. What is the (technical) gain is for being in the trunk? >> 2. Concerns about external release schedule pressure >> 3. Why have something on the trunk if it's not eventually destined for a >> release? >> >> In particular, I think B2 and C1 seem to be in conflict with each other. >> >> I have several thoughts about this topic, but I'm hesitant to continue this >> already lengthy thread on a contentious topic. I also don't want to spend >> the next 30 minutes writing a lengthy, carefully-worded email that will just >> spawn further lengthy, carefully-worded emails (each costing 15-30 minutes). >> Prior history has shown that we discuss and resolve issues much more >> rationally on the phone (vs. email hell). >> >> I would therefore like to discuss this on a weekly Tuesday call. >> >> Next week is bad because it's the MPI Forum meeting; I suspect that some -- >> but not all -- of us will not be on the Tuesday call because we'll be at the >> Forum. >> >> Thomas indicated there was no rush on the RFC; perhaps we can discuss this >> next-next-Tuesday (June 10)? >> >> >> >> >> On May 27, 2014, at 12:25 PM, Thomas Naughton <naught...@ornl.gov> wrote: >> >>> >>> WHAT: add new component to ompi/rte framework >>> >>> WHY: because it will simplify our maintenance & provide an alt. reference >>> >>> WHEN: no rush, soon-ish? (June 12?) >>> >>> This is a component we currently maintain outside of the ompi tree to >>> support using OMPI with an alternate runtime system. This will also >>> provide an alternate component to ORTE, which was motivation for PMI >>> component in related RFC. We build/test nightly and it occasionally >>> catches ompi-rte abstraction violations, etc. >>> >>> Thomas >>> >>> _________________________________________________________________________ >>> Thomas Naughton naught...@ornl.gov >>> Research Associate (865) 576-4184 >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> Link to this post: >>> http://www.open-mpi.org/community/lists/devel/2014/05/14852.php >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/05/14904.php >> > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/05/14905.php
