[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]

Hi Joe,

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.


> I think encouraging abstraction and RFC-aware flexibility is fine, but I
> think it is unwise to suggest that we should block *working code* from
> getting in just because a bigger, different or more-deluxe RFC exists.  RFCs
> and the widespread desire for a feature flavor X are really quite removed
> from a working implementation ready for action, testing and revision now.
>
>
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.


> 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. That assertion is within their prerogative as a vendor, however,
it is equally possible that the community consensus may be to use 'foobar'
rather than 'foo' and so away we go on a different path leaving said vendor
to sink or swim on their own fork.

2. Given the problems we already have with a lack of development
cooperation, this scenario at best does nothing to address those problems.

3. This scenario appears a bit "vendor-centric." I am of the opinion that
Koha should be "community-centric" with individual's first and vendor's
second in order of relationship. 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. Yes, I realize there are other FOSS ILS's available.
However, the point is that many Koha support vendors (especially the names
you mention earlier) came into existence because of Koha. I think it is in
their best interest to help assure the survival of the community by putting
in as they take out, and it is the community as a whole that decides the
"rules" (if you will) for putting in.

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

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.

Kind Regards,
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/5899c84a/attachment.htm>