On Mon, Aug 29, 2016 at 11:03:45PM +0300, Yishai Hadas wrote:

quoted

Remember, most of the code is dead, the maintainer is MIA or hasn't
accepted a patch in months or years.

Agree, that's why I think that such dead providers code shouldn't be put and
maintained with live providers, it doesn't make sense.
How many providers/libraries in this GIT are really active ?

What? That is backwards. The best way to carry 'finished' code is in a
live and active repository, otherwise it just tends to bitrot into
failure.

Having it be an active part of day-to-day developer work flows is the
best way to keep 'finished' code compiling and working over the long
run.

This is how the kernel flow has worked for many years and it largely
is proven to be a success.

For instance, with rdma-plumbing it would have been trivial for Steve
to at least compile test his ARM64 enablement across all providers.

It was easy for me to fix the pthread mislinking across all providers.

It will also be easy to do 'build and run in place'.

Let alone things like Covarity, Travis CI and other tooling that is
cumbersome to access across 15 different source trees.

quoted

mlx4/mlx5 is an notable exeption. You and Doug should work out a
reasonable appraoch. Maybe he takes your pulls directly, maybe you
have co-commit access on Github (the team approach), something else?

We definitely need to close this point before going a head into any solution
that might block a fast progress of accepting/merging new code of
live/maintained projects as of libmlx4/5.

The obvious channel for something like your TSO example is the same as
the kernel, Doug takes the common code and the only implementation
(mlx5) together at the same time.

This is pretty much what we have been doing on the kernel side.

There is zero reason to delay the driver side once the verbs side is
OK.

I'm looking at the git commit activity on mlx4 and mlx5 and I honestly
don't see your concern, the commit rate is maybe 1 series every 3
months on mlx5 and even less on mlx4. Nothing here is so active that a
combination would be a significant negative, and by far the majority
of it is tied to verbs features anyhow.

quoted

quoted

quoted

This is already basically the case, you need to wait for Doug to take
any libibverbs changes before you can push any provider feature
change. 

This is incorrect, when Doug is taking into libibverbs, vendor code that is
ready can be taken immediately, the new approach might cause some extra
delays and slowness.

I haven't seen you do that.

What are you talking about ?

We are having troubles with English, apparently.

Sure that we take *only* code that works with upstream libibverbs. Both
libmlx4 and libmlx5 are *always* in a ready state for a release with latest
libibverbs.

So nothing changes.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html