[ofiwg] agenda for 8/12 meeting
sean.hefty at intel.com
Tue Aug 12 15:05:30 PDT 2014
> I missed the webex meeting today and apologize if some of the following was
> already considered for the face-to-face meeting agenda. I'd like to discuss
> some of the issues related to starting a new open source project, how to
> enable concurrent development, etc. No need to address these on the mailing
> list, just something to think about at the meeting next week.
I currently have 2 source trees available on git.openfabrics.org 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.
I think this is a topic which could fairly easily be covered in the weekly OFIWG calls.
> Also, I have some questions about the libfabrics implementation.
> - Are vendors expected to implement additional 'providers' as opposed to
> close-source implementation of the libfabric interface?
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.
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.
> - If multiple libfabric implementations are allowed, how do we ensure
> compatibility (required library naming conventions, etc) to allow
> middleware to link/dlopen different libfabric libraries?
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.
> Open source
> - license, contributor agreement, etc?
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).
> - location of top level git repositories
> Development process
> - commit authority
I think github gives us an advantage supporting multiple people with commit authority, versus using openfabrics.org.
> - code review (sign-off) requirements?
> -- only 'blessed" (interface) files?
> -- all files?
> -- no files - sign-off not needed?
I would say all patches need a sign-off line
> - git merge vs git rebase
> -- development branches
> - release management (branches)
> -- 'stable', 'alpha', 'beta', 'next', etc
> - trac database?
> -- bug reports
> -- interface changes
> - how to obtain agreement on proposed interface changes
> -- early bringup - less control
> -- more interface control needed when dependent projects are
> started (provider implementations, middleware prototypes, etc)
These seem like good topics for discussion at the F2F or during one of our weekly meetings.
More information about the ofiwg