[openfabrics-ewg] Where do contribute new stuff to OFED scripts?

[Jeff Squyres]

On 9/15/06 8:01 AM, "Michael S. Tsirkin" <mst at mellanox.co.il> wrote:

>> 3. Why not use SVN as a collaboration tool rather than sending patches
>> around?  It seems quite inefficient to send a patch for every little thing
>> that needs to be done (some OMPI scripting improvements, allowing
>> system-wide/per-user MPI selection, etc.).  Patching creates more work for
>> everyone (create the patch, verify the patch, test and apply the patch... By
>> which time the patch may have become stale).  We have a shared development
>> area (the trunk); why not use it directly?
>> 
> We should use mail for collaboration because that's how open development is
> done

Short version: I think that you are confusing policy with technology.  SVN
is a perfectly good tool for file collaboration.  If we want policies to
review submitted code by maintainers (which is a Good Thing), SVN can do
that.

Longer version:

Sweeping statements such as "that's how open development is done" are
typically easy to poke holes in with counter-examples.  :-)  I'd agree that
*some* open development is done that way.  But certainly not all.

For example, we don't send patches around in the Open MPI project (another
global, multi-organization programming project).  The OMPI SVN maintains a
trunk where developers work and branch off it for releases.  SVN permissions
are set such that only release managers can commit to release branches;
reviews come from the trunk before they are SVN merged to the appropriate
release branch(es).  Longer-lived developments make temporary branches and
eventually merge back to the trunk, reviewed as appropriate.

Isn't this more-or-less the way that the trunk development is done in
OpenIB?  Why should OFED be different?

Also: don't we all get too much mail already?  I know that I do (hundreds a
day -- I know that others get thousands).  I lose too much critical mail
already.  SVN was designed for file collaboration; why force e-mail to
handle programming tasks when we have a perfectly good tool for code
collaboration?

> - so that  review is possible.

Review is certainly possible without sending patches around.  More
specifically: e-mail is not the only way to conduct reviews (indeed, I'd
maintain that e-mail is a very poor tool for it).

> Having everyone checking in stuff without review by maintainer is wrong.

What if I'm the maintainer?

Also, you didn't answer my other questions.  For example: who would be the
gatekeeper of the patches that are sent, and where would they be stored
until the next release branch is created?  (perhaps on the trunk?  Hmm!)

I'm trying to say that our current OFED SVN usage does not:

A) use SVN to its potential
B) allow for non-release development
C) provide controlled drops from development (OFED releases *are* active
development, which just seems weird)

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems