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

[Joe Atzberger]

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 *...".

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.  Right now we can't even
get comment on RFCs, let alone dedicated VMs and manpower.



> 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?



> 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.



> 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.



> 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.


> 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.


> 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.


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.


> 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!


> 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.

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

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.

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/b5301581/attachment-0001.htm>