Ralph,

If you are suggesting that you will make code that breaks a current rankfile feature, note I am not talking about adding a new feature that isn't supported by rankfile but something that used to work, then I think you are acting in poor form.  At a minimum you should at least give the community a heads up that you are borking a feature.

There are a lot of pieces of code that everyone changes that require other changes that one is not completely responsible for.  If everyone decided it wasn't necessary to maintain/support those pieces our code will soon be useless (maybe it is).

--td

Ralph Castain wrote:
Read the other "no" votes, and I can understand the points made. I noted that neither respondent offered to maintain this feature, but indicated that it had some value.

There really isn't any need to make a decision about this because it will take care of itself. Since no-one is maintaining it (and I really don't have time to continue to do so), and it tends to break easily, this module will "self-deprecate" rather soon. When that happens, we can wait and see if anyone cares enough to step forward and take responsibility for maintaining it.

If not, then we can note that support for this feature went the way of other things that died due to lack of interest within the developer community (e.g., xgrid)...which is totally okay since this is, after all, an open source effort.


On Apr 15, 2010, at 4:00 PM, Jeff Squyres wrote:

  
WHAT: Deprecate the "rankfile" component in the v1.5 series; remove it in the 1.7 series

WHY: It's old, creaky, and difficult to maintain.  It'll require maintenance someday soon, when we support hardware / hyperthreads in OMPI.

WHERE: svn rm orte/mca/rmaps/rank_file

WHEN: Deprecate in 1.5, remove in 1.7.

TIMEOUT: Teleconf on Tue, 27 April 2010

-----

Now that we have nice paffinity binding options, can we deprecate rankfile in the 1.5 series and remove it in 1.7?

I only ask because it's kind of a pain to maintain.  It's not a huge deal, but Ralph and I were talking about another paffinity issue today and we both groaned at the prospect of extending rank file to support hyperthreads (and/or boards).  Perhaps it should just go away...?

Pro: less maintenance, especially since the original developers no longer maintain it

Con: it's the only way to have completely custom affinity bindings (i.e., outside of our pre-constructed "bind to socket", "bind to core", etc. options).  ...do any other MPI's offer completely custom binding options?  I.e., do any real users care?

-- 
Jeff Squyres
jsquyres@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/


_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
    


_______________________________________________
devel mailing list
devel@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Oracle
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.650.633.7054
Oracle - Performance Technologies
95 Network Drive, Burlington, MA 01803
Email terry.dontje@oracle.com