[ewg] Re: [ofa-general] OFED Jan 28 meeting summary on RC3readiness

[Doug Ledford]

On Wed, 2008-01-30 at 14:03 -0800, Sean Hefty wrote:
> >The main reason is not the bugs but the features supported by IBM - CM
> >support for non SRQ and 4K MTU
> 
> These are entirely my opinions, but...
> 
> OFED isn't even at RC1 if it's not at feature freeze...
> 
> OFED has moved well beyond trying to provide an enterprise distribution to
> simply providing an experimental code base more concerned with including the
> latest and greatest features.  It's become the staging area for getting the code
> into shape for merging upstream, which wasn't what I thought was the purpose of
> OFED.

Well, that's not really a fair thing to say given that the CM support
for non SRQ patch *is* upstream, it just isn't in OFED.

As far as OFED not even being at RC1 if it isn't at feature freeze, that
all depends on what's classified as a feature.  I know the two patches
above were called features by Tziporet, but if this were an internal Red
Hat project, those would have been more correctly classified as
blockers.

Once we've passed our feature freeze deadline and started our testing
and validation, if a bug or shortcoming is found in some new code we
submitted, then that is classified as a blocker (unless it's actually
unimportant enough that we can leave it, but there are very few of this
sort of thing ever found).  For us anyway, this will be our first
release where we are turning on CM support in IPoIB.  It would be a
legitimate bug that the code as submitted doesn't work across all the
hardware.  So, that would be a blocker bug, with the fix being the
non-SRQ support.

Anyway, I got the impression that the real sentiment of your mail was
less about those two bugs/features and more that OFED seems to be more
of an experimental source repo than an enterprise distribution.

In all fairness, the kernel portion of all of this, and the process of
getting things into Linus' kernel, has *always* been a case of staging
things in Roland's tree and then merging upstream.  So, at least for the
kernel, that's mostly true as OFED is pretty close to Roland's tree
generally speaking.  As for the user space packages though, you guys
*are* the upstream.  There's no one to merge upstream to and very little
oversight by anyone.  So, it's entirely up to all of you just how much
your package seems to be a feature of the day change-athon versus a
solid, stable program.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080130/f29ec737/attachment.sig>