[ofiwg] agenda for 8/12 meeting

[Hefty, Sean]

> 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.