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

[Jeff Squyres]

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

>> 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).
> 
> Seems to work fine for linux and the rest of openib stack, so we'll stick to
> it.

1. The OFA is a group collaboration.  When a problem is raised by a member,
I think reasonable discussion is warranted before an individual can make a
sweeping decision.  :-)

2. Your citation is incorrect.  Linux development, although it deals with
patching and merging, uses git (a *tool*, not e-mail -- try e-mailing a
patch to Linus and see what happens ;-) ).  OpenIB developers all work on
the trunk, not release branches (OFED is *developed* on release branches).

3. I'll say it again: e-mail is a very poor tool for collaborative coding
(no version history, no identity authentication, no global tracking /
visibility, ...etc.).  There are tools that are specifically written for
this kind of stuff; we should use those.  Oh, wait -- we *are* using one:
SVN!  :-)

>> Also, you didn't answer my other questions.  For example: who would be the
>> gatekeeper of the patches that are sent,
> 
> Vlad Sokolovsky vlad at mellanox.co.il has written these scripts so he's the
> maintainer.

But he's not the maintainer of all the content in OFED; I'm the maintainer
of Open MPI, for example.

Regardless, if I have updates for his scripts (which I do), having a policy
of getting them reviewed by the maintainer is different than using a tool to
maintain the collaborative work.  Reviews are good.  Tools designed for
specific tasks (like collaborative coding) are also good.
 
> So far no one was interested in reviewing his code, so I did all review
> offline.
> We'll ceraintly be glad to get some help here.

That's great, too, but that's not what I was asking about.
 
>> and where would they be stored
>> until the next release branch is created?  (perhaps on the trunk?  Hmm!)
> 
> First thing after release Vlad  plans tosplit scripts for
> kernel and userspace code. Kernel stuff will stay in git close
> to kernel code, userspace in svn trunk with userspace.

So is the OFED code in the trunk totally bogus at this point?  If so, it
should be removed (and, IMHO, re-created with proper content).

>> 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)
> 
> As I see it, in distributed environment such as ours ideally there would be
> topic branches for development and branches can get merged when ready.  SVN
> does
> not easily support it - frequent merging there is quite painful. Hopefully
> we'll
> just switch to git for userspace too.

Again, you are making sweeping generalizations that reflect your opinion.
For example, we use SVN merging frequently in the Open MPI project and it
works nicely for us.  FWIW, SVN was specifically designed for cheap
branching and merging.

My point is getting lost in all of this back-and-forth:

- E-mailing patches around is *not* a good way to write collaborative code
- There is currently no place for non-release OFED development
- OFED is not following the same development model as the rest of OpenIB
- We have an established collaboration mechanism (SVN) and the OFED process
is not using it well

OFA is about working together to make high-quality software.  It seems like
we're funneling all work down to a single bottleneck in the release process
(a process that is not well defined, and is different than the rest of
OpenIB).  It doesn't need to be that way; lots of other projects (to include
Open MPI) allow a much more open model and get greater throughput as a
direct result.  

Case in point: I still don't know how to contribute my new work back to
OFED.  You said "mail a patch", but didn't answer any of my followup
questions (e.g., I don't know what version to patch against, when it will be
applied, where it will live until then, ...etc.).  If OFED was developed on
the trunk like the rest of OpenIB, this would not be an issue; I could
commit on the trunk (or a branch to let Vlad review) and it would not be
applied to the v1.1 branch, but would automatically be included in the v1.2
branch when it is created.  Regardless, the work would not get lost in INBOX
overflow -- it would be permanently and globally available in the SVN
history.

Specifically: the OFED release process has been loosely defined by Tziporet
in some e-mails that she sent a while ago that I *might* be able to dig up
after searching for it (e-mail is not a good repository for this kind of
information due to the volume that we each receive every day).  But the OFED
development process has never been defined (hence, this discussion).  IMHO,
it needs to be.

-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems