[openfabrics-ewg] Getting EWG off to a rapid and positive sta rt
Yaron Segev
yarons at voltaire.com
Sun Mar 19 09:25:19 PST 2006
Seems like Voltaire is OK for the below proposal.
Proposed Voltaire Maintainers and B- Maintainers list was already
communicated to the mailing list.
YaronS
___________________________________________________________
Yaron Segev | +972-9-9717650 (o) | +972-54-4996631 (m)
Director, Software Development
Voltaire - The Grid Backbone
www.voltaire.com <http://www.voltaire.com/>
______________________________________________
________________________________
From: openfabrics-ewg-bounces at openib.org
[mailto:openfabrics-ewg-bounces at openib.org] On Behalf Of Florin, Reini
Sent: Thursday, March 16, 2006 9:52 PM
To: Openfabrics-ewg at openib.org
Subject: RE: [openfabrics-ewg] Getting EWG off to a rapid and positive
sta rt
Speaking for SilverStorm, I agree fully with Sujal's process suggestions
and process proposal below with one added comment.
Since the EWG will be a distribution not a release, I think it is
important that we make sure we cover the two primary goals that were the
genesis of the EWG concept 1) Provide a single distribution to users
that has multivendor guaranteed component interoperability and 2)
Provide a distribution to users that has supportable, enterprise class
components
I suggest that the distribution, in addition to the "support" based
classifications Sujal suggests below also incorporate "interoperability"
based logic in the component classifications.
One suggested expanded definition approach to Sujal's below:
1) Basic Component = All vendors that will be offering the EWG
distribution to the market agree to interoperability, enterprise
quality, and support for basic components (IE. Core, IPoIB, etc.)
2) Add-on Component = Full multivendor interoperability and support is
not guaranteed to the user for an add-on component but the component is
guaranteed to be enterprise quality and support for the component is
provided by one or more vendors (IE. iSER, SRP, SDP, etc)
3) Technology preview = No multivendor interoperability guarantee and no
vendor support at all ..... these components are at your own risk
components in the distribution (MVAPICH?)
Reini Florin
Vice President of Marketing
SilverStorm Technologies
780 Fifth Ave, Suite 140
King of Prussia, PA 19406
Tel: 610 233-4854
Cel: 203-906-3570
Fax: 610 233-4777
E-mail: rflorin at silverstorm.com
www.silverstorm.com
-----Original Message-----
From: openfabrics-ewg-bounces at openib.org
[mailto:openfabrics-ewg-bounces at openib.org]On Behalf Of Sujal Das
Sent: Thursday, March 16, 2006 1:51 PM
To: Openfabrics-ewg at openib.org
Subject: RE: [openfabrics-ewg] Getting EWG off to a rapid and
positive sta rt
Bryan ,
Thanks for leading the discussion. I have tried to address some
of the questions in the proposal below.
All,
Here is a strawman proposal for the EWG Distribution process. I
would like to call a meeting of the EWG members on Monday between at
11:30 AM PST (this time works for the folks in Israel). PLEASE CONFIRM:
KEY PEOPLE in the process:
1. The EWG needs a CHAIR, per Open Fabrics Bylaws who needs to
be approved by the BOD. The Chair is a liaison between the EWG and the
BOD. Will communicate the existence and purpose of the EWG to
OpenFabrics-General.
2. RELEASE COORDINATOR who drives the upcoming release. Drives
decisions collaboratively to enable stable, supportable release of EWG
Distribution on schedule. Defines: Which software components are
included? Which hardware components are intended to work?
3. Open Fabrics Release Committee Lead - the OFR LEAD (what
Bryan from PathScale is today)
4. TEST LEADS from each Company. Decides: Which distros are
targeted? What is the test matrix? What documentation will be written up
for customers?
5. MAINTAINERS and backups (B-MAINTAINER) for each component in
EWG: Calls dedicated technical meetings to ensure delivery, code/feature
completeness.
Suggested schedules:
EWG Distribution 1.0 - sync with OFR Release 1.0 date of May 8.
EWG Distribution 1.1 - Sept (4 months delta between releases)
Proposal for electing the KEY PEOPLE:
1. CHAIR is elected on a rotating basis - changing every 4
months with EWG release completions. Represented by system companies -
Cisco, Voltaire, SilverStorm. In alphabetical order. So, starts with
Cisco as the CHAIR. Storage vendors like LSI if they meet the criteria
to a EWG member can be eligible to be CHAIR as well. First proposed
rotation is after EWG Distribution 1.1 (May 8 being too close). If that
is a problem, it could be Matt representing a neutral party.
2. RELEASE COORDINATOR is elected from either Mellanox or
PathScale on a rotating basis - changing every 4 months with EWG release
completions. Change will be decided when the time comes based on voting
or recent past effectiveness etc. This person must be commercially
neutral to the system companies who compete in the end user space. At
any time Mellanox or PathScale will be the RELEASE COORDINATOR or OFR
LEAD, not both. Currently Pathscale is OFR LEAD. So Mellanox will be
RELEASE COORDINATOR. First possible rotation (based on voting,
effectiveness etc.) is after EWG Distribution 1.1 (May 8 being too
close)
3. OFR LEAD is elected from either Mellanox or PathScale on a
rotating basis - changing every 4 months with EWG release completions.
Change will be decided when the time comes based on voting or recent
past effectiveness etc. This person must be commercially neutral to the
system companies who compete in the end user space. At any time
Mellanox or PathScale will be the RELEASE COORDINATOR or OFR LEAD, not
both. Currently Pathscale is OFR LEAD. So Mellanox will be RELEASE
COORDINATOR. First possible rotation (based on voting, effectiveness
etc.) is after EWG Distribution 1.1 (May 8 being too close)
4. TEST LEADS - elected by individual companies. Scott from
Cisco, Bob from SST, Moni from V, Amit from Mellanox, Betsy from
Pathscale.
5. MAINTAINERS (B-MAINTAINERS): Selected based on who is
currently maintaining. MAINTAINER selects B-MAINTAINER based on
technical expertise, past contributions. Here are MAINTAINERS and
suggestions for B-MAINTAINERS:
o MTHCA - Roland (Michael Tsirkin)
o IPATH - Roland (Bryan)
o Core - Roland (Bryan)
o IPoIB - Roland (Eli Cohen)
o SDP - Michael Tsirkin (?)
o SRP - Roland (Vu)
o iSER - Moni (?)
o RDS - Todd (?)
o MVAPICH - ?? (ideally would like companies with vested
interest to productize MVAPICH)
o Open MPI - ?? (ideally would like companies with vested
interest to productize Open MPI)
o OSM - Eitan (Hal) (ideally would like companies with vested
interest to productize OSM)
o Diagnostic Tools - Eitan (Hal)
RELEASE COMPONENT CATEGORIES:
They fall under 3 categories:
o BASE COMPONENTS: IPoIB, SDP, SRP, iSER, RDS, Open MPI, iPath,
MTHCA
o Depending on vendors desire/ability to qualify and support
BASE COMPONENTS - some may be released and supported by vendors as TECH
PREVIEW only. E.g., iSER could be TECH PREVIEW for Cisco. SRP could be
TECH PREVIEW for Voltaire. RDS could be TECH PREVIEW for all etc. The
goal is to get TECH PREVIEW components graduate to supported BASE
COMPONENTS in the EWG Distribution 1.1 scheduled for September.
o ADD-ON - These will be added in Vendor specific distributions
as add-ons on top of (and not replacing) BASE COMPONENTS. OSM,
Proprietary SM, Proprietary MPI, other value added management and tools
etc fall in this category
EWG DISTRIBUTION MANAGEMENT + SYNCH WITH OFR RC BRANCH
Copy a specific trunk/branch version to EWG area you can call
this a tag. The main idea of a tag is that you do not commit changes to
the tagged area.
In addition there is a directory called patches where EWG places
the fixes wanted that were not in the trunk/branch. The OFR LEAD folds
those into the OFR-RC branch immediately. Coordinated with RELEASE
COORDINATOR as necessary.
Continue copy of trunk/branch to the tag few times till EWG gets
to the point it wants to freeze code. >From this point (regression test
phase) EWG only adds patches (some can be EWG fixes and some from the
trunk/branch).
We need a discussion on the contents of the OFR rc1 branch -
whether it meets the need of end users defined by the EWG and if that
needs to be updated (as rc2) based on feedback from EWG.
Thanks
Sujal
-----Original Message-----
From: Bryan O'Sullivan [mailto:bos at pathscale.com]
Sent: Thursday, March 16, 2006 9:36 AM
To: Openfabrics-ewg at openib.org
Subject: [openfabrics-ewg] Getting EWG off to a rapid and
positive start
Hello -
I'll be PathScale's engineering and testing representative on
the EWG.
I would suggest that we start by clarifying the goals of the EWG
process, so that everyone is in sync.
My principal interest is in ensuring that there is no duplicated
or
wasted effort between the 1.0 process and the EWG process, and
that each
can proceed at its own appropriate pace with maximal cooperation
between
the two.
What I believe is a good way to achieve this is as follows.
Somebody needs to articulate the goals of the EWG process, and
the
timeline in which it will take place. Here are some suggestions
I have.
* The existence of EWG should be made public on
openib-general,
and it must be made clear that there is cooperation, not
duplication, between the 1.0 and EWG processes.
* Which software components are included?
* Which hardware components are intended to work?
* Which distros are targeted?
* What is the test matrix?
* What documentation will be written up for customers?
* How long is the support window?
* What's the policy with respect to switching to the
official 1.0
and subsequent releases?
To get the testing and defect fixing balls rolling as quickly as
possible, EWG contributors ought to use the 1.0 release
candidate tree
at https://openib.org/svn/gen2/branches/1.0/ as its initial
basis for
source code to build and test. You can download source tarballs
and
some RPM packages from http://openib.red-bean.com/
It's fine with me if EWG branches from 1.0 so that it can
proceed at its
own pace. However, if this happens, there must be frequent
merges
between the two trees, because clearly everything that happens
in one
branch ought to be beneficial to the other.
The mechanism that EWG uses to track defects should be OpenIB
Bugzilla.
I believe it's already configured in an appropriate manner. If
not, I
will be happy to make any needed changes, or ask our colleagues
at
Sandia to help out.
<b
_______________________________________________
openfabrics-ewg mailing list
openfabrics-ewg at openib.org
http://openib.org/mailman/listinfo/openfabrics-ewg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20060319/a9c852a5/attachment.html>
More information about the ewg
mailing list