[openfabrics-ewg] Draft IBED Positioning Statement

[Tziporet Koren]

Scott Bahling wrote:
> Hi,
>
> I have been following this thread, and see some confusion about the
> difference between the OpenFabrics 1.0 release and the IBED release. To
> me it seems clear, because it matches the way we create our distros.
> There are official community releases of packages that make up the base
> of our distro. The same would be true for IBED which grabs code from
> OpenFabrics, kernel.org, Open MPI, OSU MPI, etc...
>
> One tip - IBED should not fork to far, if at all, from these community
> code bases. Any patches that end up in IBED should come from (backported
> if necessary) the official community trees. This means if bug is first
> found in IBED, we need to get it fixed in the community tree first. If
> we don't do this, we will end up with code that is difficult to maintain
> for any length of time.
>   
This is exactly the way we are working on IBED right now. Each bug we 
find is first being fixed on the trunk, and then we merge it to the 
release branch.
> What is not clear to me is the stability commitment behind IBED. As an
> enterprise customer (end user or ISV), I would expect in that in the
> IBED minor releases there are no regressions in functionality or
> interfaces (API/ABI), and no (appreciable) regressions in performance
> from the initial release major release (1.0?).
>   
We are doing performance measurements on the following:
Basic verbs, MPI, IPoIB and SDP. In all the target is that the 
performance will be equal or better each release. Of course some time 
there is a degradation of the performance due to changes in the kernel 
(like IPoIB).
> The IBED minor releases should provide bug and security fixes and
> possible feature enhancements that have been QA'd to ensure no
> regressions as stated above. Immediate bug fixes can be delivered to
> customers by the distros or vendors, but are eventually rolled into the
> standard release. Any fixes to customers should be approved and
> submitted to the IBED (and parent community releases if not already
> there) svn before providing to the customer - that way insuring the fix
> is standardized, and makes it in the next general release.
>
>   
I agree.

Tziporet