All he is doing is pushing intermediate steps upstream to maintain contact and gain familiarity. No harm done as the code isn't built by default.
Broader design discussion can take place as we understand the problems Sent from my iPhone > On Dec 4, 2013, at 12:07 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> > wrote: > >> On Dec 4, 2013, at 11:29 AM, Ralph Castain <rhc.open...@gmail.com> wrote: >> >> Jeff - you are jumping way ahead. I already said this needs further work to >> resolve blocking. These patches (per Adrian's email) just makes things >> compile > > Fair enough. > > But in some ways, having uncompilable code is a *good* thing, because it > tells you exactly where you need to work on the architecture. Just updating > it to *compile* removes that safeguard -- will you remember/re-find all those > places where it *used* to block and convert the architecture to workaround > the blocking? > > I guess I'm saying: what exactly does updating it to compile get for us, if > we know the code still won't work? It seems like all we'll be doing is > removing the grep-able places where we *know* we'll have to do work in the > future. > > -- > 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 > http://www.open-mpi.org/mailman/listinfo.cgi/devel
