[ewg] Notes from "Improve the OFED Development Process" at Sonoma

[Ryan, Jim]

Betsy, I'd like to thank you and the team for this. This is no doubt one
of the most important sessions of the workshop, and set of decisions and
actions

Regards, Jim

-----Original Message-----
From: ewg-bounces at lists.openfabrics.org
[mailto:ewg-bounces at lists.openfabrics.org] On Behalf Of Betsy Zeller
Sent: Tuesday, April 22, 2008 10:49 PM
To: ewg at lists.openfabrics.org
Subject: [ewg] Notes from "Improve the OFED Development Process" at
Sonoma

Here are the notes from the "Improve the OFED Development Process"
session at Sonoma, including issues, proposals, questions and comments,
collected from the session. I wanted to get the notes out in front of
everyone before we forget what we actually talked about. Once people
have had a chance to review them, we can follow up and determine how to
execute. (Note, I'm out of town and away from email till next Monday, so
hopefully other panelists will respond to questions and comments - no, I
didn't plan it that way!)

- Betsy

Issues
1) How do we ensure we achieve enterprise quality?
PROPOSALS:
a) Evaluate features early in the process, so everyone
is aware of potential impact -  eg, API changes, performance
impact on other components, (NOTE: we need a checklist)
b) Make it clear to all participants that OFED is not
intended to be an experimental release. Components can
be marked as "tech preview", but it is not OK to put
experimental changes in already released protocols.
c) Authors of changes to ULPs, or SW that may affect
many HW vendors should submit a list of potential affected
HW, along with a list of which HW they have tested on.

2) What do we do to minimize slippage of release date?
PROPOSALS:
a) Clear definition of feature vs bugfix
b) Clear statement and communication of feature freeze date
c) Review proposed features, including  what impact they might
have on other components, such as drivers or ULPs
d) Especially for late bug fixes, the implementor has to be responsible
for making sure the change doesn't impact other SW components,
or other vendors hw.

PROPOSAL: Make OFED a date driven release. Implies that for
last period (4 weeks?) of release, only specific bug fixes
are allowed.

3) Process for fast turnaround, single vendor bugfix.
DOCUMENT on Open Fabrics webpage:
- submit patch
- get nightly build
- vendor tests
- all recognize that sub-minor (4 release numbers) means that
this is for one vendor - or, can we actually use something like:
1.3.1.1.q, to indicate a bugfix release from QLogic (NOTE: need
decision)
- fix needs to be rolled into next point release
- Download page from openfabrics.org has only fully qualified,
tested releases

4) QUESTION: Does kernel code always need to come through kernel.org?

PROPOSALS:
a) SDP is an exception, as "existing non-conforming" - it will
not be submitted to kernel.org
b) IB kernel developers will try to get changes into kernel first,
to be pulled down into OFED. If they miss the "kernel train",
changes should be submitted to next available kernel. Developers
should try to make sure their changes are in Roland's queue, even
if they are not actually in the kernel.
c) Components (other than SDP) which are not currently in the kernel
should be submitted there. (eg, RDS - what else?)

QUESTION: What happens if a component is not accepted to kernel?
- if it is because of code style/quality - fix it
- if not considered appropriate feature for kernel - discuss it, but
how do we resolve it? Note that we really don't want a component
which is not in the kernel, and which has no long term owner
- other possible reason for rejection is that it is legally
inappropriate,
that is, either wrong license/copyright, or disputed patent, or
something
similar. This should not be taken into OFED.
QUESTION: How do we make sure "fix-up patches" get submitted to
the upstream kernel?
COMMENT: All can benefit from the kernel review process.
COMMENT: We don't want to end up in a situation where the same
functionality
is handled one way in OFED, and another way in the kernel

5) Improve Housekeeping
PROPOSAL:  Review licenses/copyrights for correctness

6) Enabling Distros
QUESTION:  Is it true that RHEL doesn't take all of OFED 1.3, but
instead
pulls directly from the maintainers? (NOTE: Need followup)
QUESTION:  Is it true that RHEL and SUSE write their own backports,
rather
than using the OFED ones? (concern for us because of testing)
QUESTION:  How, exactly, are RHEL and SUSE distros put together? eg,
does
the distro just pull IB kernel support from the relevant kernel,
rather than taking OFED kernel components?
QUESTION: How do we coordinate OFED and distro releases, to maximize
opportunityfor most recent OFED release to go in newest distro release?
PROPOSAL for packaging change:
a) Aggregate kernel patches and modules into one package
b) User code
        - use tar-balls and sample RPM spec files for releases and RCs
        - use git (for daily builds) and pull script
        - distributors "roll their own"

7) Planning for interoperability events
PROPOSAL: Do interoperability initial testing on "final" RC (only
expected
changes are interop changes), and do "formal" testing on GA.

COMMENTS:
- the best way to reach enterprise quality is to submit everything
through the kernel, because of their rigorous review process
- note that submitting to Roland's queue does not automatically
mean the change goes into OFED - you have to specifically request
that it go in.


_______________________________________________
ewg mailing list
ewg at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg