<div dir="ltr">Even better : we could use Docker to build MPI app stacks (just sign up with your GitHub account). <div><br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 3:05 PM, Hefty, Sean <span dir="ltr"><<a href="mailto:sean.hefty@intel.com" target="_blank">sean.hefty@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I missed the webex meeting today and apologize if some of the following was<br>
> already considered for the face-to-face meeting agenda. I'd like to discuss<br>
> some of the issues related to starting a new open source project, how to<br>
> enable concurrent development, etc. No need to address these on the mailing<br>
> list, just something to think about at the meeting next week.<br>
<br>
</div>I currently have 2 source trees available on <a href="http://git.openfabrics.org" target="_blank">git.openfabrics.org</a> related to the ofiwg. These are separate from the source trees maintained for the current set of interfaces (libibverbs and librdmacm). I placed the new trees on openfabrics simply because it was easy for me. I don't see any issue with moving them to github.<br>
<br>
I think this is a topic which could fairly easily be covered in the weekly OFIWG calls.<br>
<div class=""><br>
> Also, I have some questions about the libfabrics implementation.<br>
> - Are vendors expected to implement additional 'providers' as opposed to<br>
> close-source implementation of the libfabric interface?<br>
<br>
</div>The suggestion is for vendors to implemented providers, not closed-source implementations of libfabric. However, the provider is not required to be open source. libfabric should provide enough hooks that a vendor can implement proprietary extensions without the need for shipping a modified version of libfabric.<br>
<br>
Note that libfabric defines an 'FI_DIRECT' mode that conceptually allows a provider to ship a proprietary implementation of libfabric. E.g. a provider has the ability to override all static inline function calls, override some enum values, etc. Applications must explicitly request support for FI_DIRECT.<br>
<div class=""><br>
> - If multiple libfabric implementations are allowed, how do we ensure<br>
> compatibility (required library naming conventions, etc) to allow<br>
> middleware to link/dlopen different libfabric libraries?<br>
<br>
</div>Ultimately the man pages should define the expected behavior of all APIs. And if we have a complete test suite, there would at least be a mechanism for validation.<br>
<div class=""><br>
> Open source<br>
> - license, contributor agreement, etc?<br>
<br>
</div>Current license from OFA is dual BSD/GPLv2. Contributions simply must contain a signed-off-by line agreeing to the dual license. All OFA Linux software has worked this way so far without issues. *IF* the ofiwg ever does anything with Windows, OFA has a different license model (BSD-only).<br>
<div class=""><br>
> - location of top level git repositories<br>
><br>
> Development process<br>
> - commit authority<br>
<br>
</div>I think github gives us an advantage supporting multiple people with commit authority, versus using <a href="http://openfabrics.org" target="_blank">openfabrics.org</a>.<br>
<div class=""><br>
> - code review (sign-off) requirements?<br>
> -- only 'blessed" (interface) files?<br>
> -- all files?<br>
> -- no files - sign-off not needed?<br>
<br>
</div>I would say all patches need a sign-off line<br>
<div class=""><br>
> - git merge vs git rebase<br>
> -- development branches<br>
> - release management (branches)<br>
> -- 'stable', 'alpha', 'beta', 'next', etc<br>
> - trac database?<br>
> -- bug reports<br>
> -- interface changes<br>
> - how to obtain agreement on proposed interface changes<br>
> -- early bringup - less control<br>
> -- more interface control needed when dependent projects are<br>
> started (provider implementations, middleware prototypes, etc)<br>
<br>
</div>These seem like good topics for discussion at the F2F or during one of our weekly meetings.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
ofiwg mailing list<br>
<a href="mailto:ofiwg@lists.openfabrics.org">ofiwg@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofiwg" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Barbara Collignon - Software Architect, Team Leader</div><div><span style="background-color:rgb(255,255,204)">Mobile</span> <span style="background-color:rgb(255,255,204)">Supercomputing</span> Technologies</div>
<div>@Beckersweet (<a href="http://www.beckersweet.com/" style="color:rgb(17,85,204)" target="_blank">www.beckersweet.com</a>) </div><div>@RmdStudio (<a href="http://www.rmdstudio.com/" style="color:rgb(17,85,204)" target="_blank">www.rmdstudio.com</a>)</div>
<div>@IRMACS (<a href="http://www.irmacs.sfu.ca/" style="color:rgb(17,85,204)" target="_blank">www.irmacs.sfu.ca</a>)</div></div>
</div>