[Koha-devel] A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]

[Chris Nighswonger]

On Tue, Nov 2, 2010 at 11:08 PM, Joe Atzberger <ohiocore at gmail.com> wrote:
> On Tue, Nov 2, 2010 at 4:12 PM, Chris Nighswonger
> <cnighswonger at foundations.edu> wrote:
>>
>> On Tue, Nov 2, 2010 at 2:10 PM, Joe Atzberger <ohiocore at gmail.com> wrote:
>>>
>>> Chris, I disagree that the first sign-off on a major vendor's patches
>>> should be external.  The first sign-off from a major vendor should be
>>> *internal* to their quality control process.  This was at one time the
>>> standing policy amongst LibLime and BibLibre for major changes.
>>
>> My recommendation is that we require a *minimum* of one sign-off by a
>> disinterested party. This in no way excludes a company having their own QA
>> internally and signing off. Furthermore, it really provides no impedance to
>> the entire process when one considers how simple it should be to obtain a
>> sign-off on good working code.
>
> Ok, I read that as amending "that the required sign-off for pushing to
> master be a disinterested developer" to "that a ...".

No, I think you may be reading it with an emphasis which I did not intend.

> Regarding the simplicity of signing off, I take some issue.  It is
> *severely* non-trivial to test major integration features.  Consider SIP2
> and LDAP, or something like EDI.  It can depend not just on accurate test
> data, but entire servers, network environments, remote accounts granted by a
> supplier, foreign domain/language knowledge, etc.  Sure, I'd love it for
> everybody to have a dozen signoffs.  I just think blocking code while
> waiting on a 3rd party (who by design is disinterested) to come around and
> dedicate some resources is a questionable policy.

I'm sure there are any number of features which could be tested in
very complex environments, and perhaps even more complex than those
used or anticipated by the original developers themselves. I wonder if
the original supplier of the SIP2 and LDAP features actually went to
the level of testing you describe prior to committing those features.
However, I do agree that testing should be defined in a way to ensure
that it is both effective and yet not a de facto "block" on the
acceptance of code.

>  Right now we can't even
> get comment on RFCs, let alone dedicated VMs and manpower.

The scant participation in this thread by others is very much proof of
the problem pointed out here! I find it hard to believe how few have
chimed in for as much "noise" as there is about these issues.

>
>>
>> Ahh... nothing in my recommendation suggests that "should block *working
>> code* from getting in just because a bigger, different or more-deluxe RFC
>> exists." It simply suggests we have a policy in place which will actively
>> promote some sort of community collaboration particularly on the part of
>> large shops who "should" know better than to clam up especially on large
>> feature development. That is patently bad behavior in the light of community
>> participation which is the foundation of this project. It is certainly
>> within the rights of anyone to take the source and run with it in whatever
>> way they like. They may even take it and never contribute back. However, it
>> is not within their right to do large, unilateral development and then
>> expect it to be pushed into the main codebase.
>
> Forgive me if I'm off the pulse a bit, but do these expectations exist
> today?  The release process establishes when new features are accepted or
> not, and it has been pretty explicit and clear.  The problem used to be big
> unilateral changes that weren't getting submitted (including some code that
> I wrote).  Now the problem is they're getting submitted?
>

Perhaps this point bears greater clarification. By "expect it to be
pushed" I meant particularly without any prior
discussion/RFC/community participation. What was/is going on with
LibLime/PTFS LEK is a classic example of the sort of thing which needs
to be discouraged. I refer particularly to the process. PTFS has
stated in a number of forums that once their "contract" obligations
are met, they will submit this code to the community. However, the job
is done at that point and clients will have implemented the product.
There will be a certain level of "expectation" that "new" features
"should" be pushed to the main code base. This sort of thing will
probably be more prevalent as vendors become larger. This behavior may
also be driven somewhat by the lack of a clear policy of inclusion.
Simply having a policy of "whatever you dump on us by the (largely
undefined) date that version X.Y.Z is to be released will be included"
is a recipe for disaster in the long run.

>>>
>>> Also, I think if you develop your features "in the open" (e.g., posted w/
>>> gitweb, or on github), the burden of synthesizing multiple RFCs and general
>>> "feature consensus" sentiment isn't on you in quite the same way as when
>>> changes are delivered en bloc.  A vendor has what their clients are paying
>>> for, and if other devs have an unfunded desire for extra feature X, they can
>>> follow the branch right along add the last bit themselves, all while still
>>> in development.  Whether X is pulled in by the vendor,
>>> or separately submitted by the dev to the RM doesn't really matter.
>>
>> A couple of points addressing this scenario as a whole (none of these is
>> against the principle of open development):
>>
>> 1. That scenario may work for simpler features/code. But consider the
>> current press to switch from zebra to 'foo' (any one of several suggestions
>> recently). If a vendor develops an entire replacement for C4::Search and
>> friends which centers around 'foo' in a unilateral fashion, the de facto
>> assertion is that the community must either take what they have done or
>> leave it.
>
> Or patch it, or extend it, or put in on a feature branch, or break it into
> discrete elements, or defer acceptance until sufficiently abstracted, etc.
>  If the vendor cares about it hitting mainline, then they'll follow up to do
> what it takes, within reason.  If they don't, then I don't think new policy
> requirements will affect them in the least.
>

I agree that ultimately a vendor's desire to participate will be the
deciding factor. But the fact that a policy won't affect a vendor is
not necessarily a reason to not have a policy.

>>
>> 2. Given the problems we already have with a lack of development
>> cooperation, this scenario at best does nothing to address those problems.
>
> This comes back to the question of whether you can force cooperation.  I
> don't think we can, effectively.  I support codifying expectations and best
> practices, but "requiring" disinterested, competing or downright hostile
> parties to cooperate or pretend to cooperate seems destined to fail.
>

By the very nature of things, a project such as this entails a
practical requirement of cooperation among competing parties. Just
look at all of the vendors participating. While the vast majority are
kind and well mannered toward each other, they are, in fact, in
competition with each other in some sense of the word. And I'll not
revisit my discussion of the fact that vendors and customers are in
the business of "requiring" and "forcing cooperation" with each other
all of the time in those little pieces of paper we call contracts. Now
this is not to suggest that we begin any formal contractual
relationships or that we attempt to "force" cooperation. But the
recent work by ByWater and Software.coop on the EDI code and Catalyst
and Biblibre on Biblibre's work illustrate that it is not beyond the
realm of reason to expect and even strongly encourage competing
parties to cooperate for the benefit of the thing that earns their
bread and butter. And as for downright hostile parties, they should go
elsewhere until they can leave off some of their hostility, imho.

>>
>> 3. This scenario appears a bit "vendor-centric."
>
> That's because, as has been pointed out previously, Koha's authorship is de
> facto vendor-centric.  The vast majority of Koha code historically
> originated from vendors and the majority of new code still comes from
> vendors.  Every RM worked for a vendor (or two).  I'm happy to see Koha
> institutions and cooperatives still able to contribute code back to the
> project on their own (some for longer than I've been associated with Koha),
> and I'd love to see more of it.  Right now though, the code being affected
> by proposed policies is still *mostly* in vendors' houses.
>

In spite of this, I hope we can avoid becoming vendor-centric.
"Vendor-centricity" leads to vendor dominance and control ultimately.
I am not personally aware of a vendor controlled FOSS project that
does not lean heavily in that vendor's favor. I furthermore hope that
in the future we will see more individuals in my own position of
vendor neutrality being elected to lead developer roles in the
community. There are several who I can think of that would be very
capable of filling these positions and help balance the trend you
point out here.

>>
>> I am of the opinion that Koha should be "community-centric" with
>> individual's first and vendor's second in order of relationship.
>
> OK, I know what a vendor is.  But in this context I don't know what you mean
> by "community-centric" or "individual" or "order of relationship".  If you
> just mean that community comes first, then yay, community.  I suspect we can
> escape talking about whether vendors are first, second or other class
> citizens in the community because it doesn't really matter for the proposed
> policy.
>

The problem is not one of where to "relegate" vendors in the "social"
structure of the community. Rather it is all about keeping vendors who
have relatively limitless resources from holding the controlling
interest in the community in whatever form that may take and at the
same time, clearly defining the obligations of those individuals who
*elect* to participate in the community in such a way that vendors can
transact business with some amount of certainty.

>>
>> This may not be the view of all involved. However, if it were not for
>> Koha, Koha support vendors would be out of some amount of business.
>
> And without vendors *no* version of Koha would ever have been written or
> released.  It's sorta funny that I'm the one saying this stuff, as I am not
> currently affiliated with any vendor.

I think that 1.0 was written by coders for hire (aka Katipo) and was
released by, not a vendor, but HLT, a library. So, in fact, no vendor
in the technical understanding was involved. Chris C. can correct me
if I'm wrong here.

>
>> 4. Regarding the statement "A vendor has what their clients are paying
>> for..." True, vendors are client driven. However, as I said in my initial
>> post, vendors must educate their clients as to the nature of open source.
>> Client expectations should be set based on known, published community
>> procedures. If this were properly done, many problems would be resolved.
>
> This is a good point, and I was interested to read Paul's and Ian's replies
> to it.  Building community submission and acceptance management into the
> quotes and development timelines is an important measure to take, and doing
> some education up front really will help.  Open source is different than
> other software development institutions may have contracted, so experienced
> parties may need more education than inexperienced ones.
>

I wish other vendor types would jump in. There sure has been
enough.... complaining (/me ducks) that I would have thought this
thread would be quite hot by now. As it is, I think you and I are just
getting a workout in debate... :-)

>>
>> As it is, I think vendors have a very hard time managing their own growth
>> once it reaches the ballooning point. Unmanageable growth will kill you...
>> as we have seen.
>
> Yes, I've died a couple times already!
>

I hope you keep coming back!

>>
>> In the final analysis, if each vendor pursues their own direction, we will
>> end up with a Baskin-Robins of Koha. Make the job of RM hard enough and no
>> one will want it. At some point the project dies due to leanness and
>> overextension. The strength of the project lies in the *two-way* cooperation
>> of its members. The "we have developed it: take it or leave it" approach is
>> a one-way, dead-end street for the community.
>
> Thankfully, it doesn't ever actually work like that.  No piece of code is
> accepted under the condition that it never be modified.  We don't have a
> license like that.

I understand the license and the ability to modify, but if you have a
zillion lines of code dumped on you which you will have to somehow
pick through in piece-meal fashion, extracting what you want and then
integrating it with what you have, it is highly probable (as you
mention, based on the facts of little to no responses to RFCs and
small response to this thread) that that code will drop by the wayside
and be left behind. That is not "two-way cooperation" in any
definition I'm aware of. It's death by overdose.

> Say a submitter puts up a good bunch of code representing a considerable
> amount of work, but we are going to require that some hardcoded
> configuration X is abstracted into a syspref.  If you asked them, "well, do
> you want to do it and resubmit, or do you want to wait an indefinite period
> until some random other person gets around to it, at which point you might
> have rebase issues?" I think 9 times of 10, they'll do it themselves.

On this small scale, I agree.

>  (Again, within reason.  It's not going to happen if the hangup is something
> huge like "Make it work with UNIMARC in Turkish".)

See the above paragraph.

> In short, extra signoff(s) are a fine recommendation and best practice, but
> I wouldn't support them as a strict requirement.  Also I think concrete
> technical details about how the "right kind" of development can be done will
> do more good than just the policy preferences by themselves.

I agree with you that we need concrete technical details about how the
right kind of development can be done. That is the presupposition of
this thread. However, I think they need to be formalized in written
form (call that by whatever name you like the best).

Kind Regards,
Chris