[openfabrics-ewg] Getting EWG off to a rapid and positive sta rt
Sujal Das
Sujal at Mellanox.com
Thu Mar 16 10:51:05 PST 2006
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/20060316/ba64a7bb/attachment.html>
More information about the ewg
mailing list