[openfabrics-ewg] Getting EWG off to a rapid and positive sta rt
Pandit, Ranjit
rpandit at silverstorm.com
Thu Mar 16 14:30:23 PST 2006
Sujal,
Please mark me as the maintainer for RDS.
Ranjit
Ranjit Pandit
SilverStorm Technologies
-----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 10:51 AM
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/20060316/5c604d86/attachment.html>
More information about the ewg
mailing list