On 08/05/2014 01:09 AM, Andy Grover wrote:
On 07/31/2014 11:00 AM, Jerome Martin wrote:
Well, all those three points could improve dramatically if we joined
forces
Maybe, maybe not. Let me lay it all out for you from my perspective:
PROS (of reunifying)
- Improved feature set
- Unified and larger user base helps LIO win against other target
implementations, and leads to more developers and users
- Less user confusion
- Share the maintenance/release work
- More code review -> better code quality
CONS
- Nonzero chance of disagreements about direction and features, possibly
leading to another fork, which would look REALLY bad
- Amt. of work to unify codebases
- Extra features that only benefit commercial users
- Code review delays timely bugfixes
Well, my first impression when looking at those two lists is that the
PROS are for the users and the CONS are for us. Which does makes sense,
we work harder to fix a situation that _we_ are responsible for, to the
benefit of the users.
And yes, collaborating is more difficult that coding in isolation, yes
unification takes work. But I do not get the code review problem. How we
do this is up to ... us. So we can make it as constraining or as
flexible as we feel fit.
I mean, basically what you are saying is true for almost every
Open-Source project on the planet with more than one developer, and you
are not sure it is worth it :-)
As for extra features aimed at commercial users, I am not sure what you
are referring to here. Are those commercial users Datera's customers?
I am not an employee of Datera, have currently no contact with Datera's
customers, and even though Datera agrees to sponsor me for the work I do
on targetcli et. al, they do not impose anything on me in terms of
features or direction.
And even then, if tomorrow Datera was to put me in touch with some of
their customer's bug report or request for improvement re. targetcli, I
would take it as such: a user with a real use case, using the software
in production who is giving important feedback.
Heck, now that I mention it, it might even be a good idea to actually
_ask_ Datera to put me in touch with some of their customers using
targetcli, so that I could chat with them :-)
And this is valid for RH customers too!
All I see are users. Maybe they have a commercial affiliation with
Datera, RedHat or SuSe. Good. They still are users, and their value to
me comes from the fact that they are probably using the software in the
real-world.
Just wanted to put it out there. I think it would be good, but there are
actual and potential downsides that we shouldn't ignore. What we have
now (separate public trees) might not be the worst - we're trading
bugfixes now, which is nice.. maybe we could collaborate on a feature
that would improve both, as a smaller step?
Do you have something specific in mind?
Andy, if you agree to it, I can dedicate some time this summer so that
we can work on this and come up with a plan. What do you think?
Sure if you want to start looking at stuff that'd be great, but we
should keep hashing out the other stuff too. BTW, keep in mind that
since targetcli-fb shipped in RHEL 7, I also have compatibility issues
and a stable branch to worry about, just like you. :-/
Let me be a little bold here, nothing personal though, but this needs to
be said.
You decided to fork my original code, which is great, and you had your
reasons. So far, so good. But then you _decided_ to break API and
compatibility. Given your position, that meant imposing that
incompatible version on all RH users. Given the weight of RH-base
distros, that means that you effectively painted both of us in a corner,
with contributors and users somehow in between, feet covered in wet
paint. And here we are now, with a mess to clean up, Debian users
writing scripts and configs that won't work on RHEL, etc.
Of course, you can't take the blame alone. I have my responsibility in
it too. I won't deny it. It takes two (at least) to tango. I'll leave it
to you to expand on that if you feel like it :-)
But now, we have an opportunity to make it up to the users. The
development is moving forward. There are exciting new features on the
horizon, following the introduction of the configuration API. There are
thing we both want to move toward, like a unified remote API and locking
mechanism.
If we miss that window of opportunity, then we are going to diverge even
more, and end up with two completely different beasts.
Can we please try hard not to let this happen ?
As for the "how", I think we need to structure the problem a little bit
here.
1) rtslib - This is the cornerstone. First goal should be to have a
common rtslib, no matter what we build on top of it. I am ready to
discuss API points at your convenance, whether the config API should be
part of it or split, etc. But at least let's give us a common platform
to implement locking, etc.
2) targetcli - Well, in the main branch, targetcli is going to be
deprecated eventually - post 3.x, as announced before - in favor of the
new lio shell with configuration API semantics. So I feel unification of
existing the targetcli versions is not that important, but we could
decide to work together on the new lio shell.
3) remote API - You already have that targetd thing, but this is very
low-level and I feel not so safe even with locking. What I have in mind
is to leverage the config API semantics to eventually provide
higher-level access to target configuration. We could easily join forces
on this.
But this is still a lot of work. Maybe we should have a voice chat so
that we can at least try to bind a little on a personal level and see if
this can work? I'll send you my phone number privately, just give me a
call so we can talk this out.
Best Regards,
--
Jerome Martin
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
