[openfabrics-ewg] Re: How to generate IBED releases using 1.0 branch

[Sujal Das]

Jeff,

The BOD voted to support the EWG initiative to enable IB vendors to create a
common and supportable enterprise-grade distribution - something they can
stand behind and support 24x7. The main challenge to be solved, as Dave Ford
has put forth numerous times, is supportability.

The goal is certainly to converge on one stack, but not compromise
supportability in any way.  If there is a compromise on supportability,
individual vendors will be again forced to create and release their own
snapshots of Open Fabrics that cannot be proven interoperable - we have seen
this happen from many of us as recently as the Jan-Feb.

We have two possible outcomes out of this effort:
(1) Possible confusion (since the BOD voted on this unanimously, I have my
doubts about the extent and implication of this, but one can always argue)
(2) A common, interoperable Open Fabrics distribution from all IB vendors
that they can confidently stand behind and support 24x7

I think (2) is far more important and we need to allow the team to make this
happen and not distract any further.

Come end of May, after the software is released, let's see if we have a
converged EWG and Open Fabrics 1.0.  May be we will have one, and this
discussion will be mute.  If we do not, lets re-evaluate then and see what
we can do.

-Sujal

-----Original Message-----
From: Jeff Broughton [mailto:jeff at pathscale.com] 
Sent: Monday, April 03, 2006 9:37 AM
To: Tziporet Koren
Cc: Shawn Hansen (shahanse); Openfabrics-ewg at openib.org; Sujal Das; Michael
S. Tsirkin
Subject: Re: [openfabrics-ewg] Re: How to generate IBED releases using
1.0branch

There are two interesting questions about the differences between EWG 
release and OpenFabrics:  First, why are they different?  Second, should 
they be different?

Why are they different?
Absent the participation of many of the current players, the decision 
was taken to create a release that fulfilled OpenFabrics mission of 
integration with the commercial OSes and providing production-worthy 
software.  These factors led to two crucial tactics.

1) The release should only use components in the kernel.org tree that 
was to be adopted by RedHat and SuSE. This way customers of the major OS 
distributions would have the necessary software to run OpenFabrics 
without mucking around with the kernel. The other consequence of this 
was to only release the user-level software that wasn't immediately 
destined to be in the distros.

2) Components were selected on the basis of their stability, and hence, 
likelihood that they would survive testing by the community.  There 
would be no "beta" components to confuse the consumers.

The EWG release appropriately intends to include all ULPs that customers 
have a strong immediate interest in.  SDP, in particular, is important. 
  But since SDP is not in the kernel.org tree, that forces the decision 
for the EWG release to include kernel components.  Likewise, given the 
stability of some of these packages, the notion of a technology preview 
becomes necessary.

Should they be different?
IMHO, no.  For the most part, the same players are working on both. 
There are only a few developers not represented by the organizations in 
the EWG.  Frankly, to allow these two to diverge would only be to add 
work for us all, and cause customer confusion.

It is entirely within our power to resolve the discrepancies in the 
strategy, and to make sure that there is only a single release.

-- 
Jeff Broughton
Vice President of Engineering
PathScale, Inc.
2071 Stierlin Ct.
Mountain View, CA 94043-4655
Phone: 650-934-8080

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060403/dc5c41cd/attachment.html>