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

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.

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.

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.

--joe

2010/11/2 Chris Nighswonger <cnighswonger at foundations.edu>

> Starting a new thread because this is indirectly related to Paul's request.
>
> 2010/11/2 Paul Poulain <paul.poulain at biblibre.com>
>
>>  Hello,
>>
>> I have filed RFCs for all enhancements you can expect from BibLibre in the
>> next few months. All of them are sponsored (by Saint-Etienne University),
>> and will have to be delivered to the library for a "go live" in May-2011
>>
>> * You can find them on the wiki (search biblibre rfc for3.4) :
>> http://wiki.koha-community.org/w/index.php?title=Special:Search&ns0=1&redirs=1&search=biblibre+rfc+for3.4&limit=50&offset=0
>> * You can also find them on bugzilla : i've added a saved search, shared
>> with everybody, called "Koha 3.4 enhancements".
>>
>> They are only related to serials and acquisitions.
>>
>> What's the next step ?
>> * read the RFCs
>> * comment them (on the wiki or on bugzilla)
>> * we will probably propose/organise an IRC meeting to discuss & get any
>> feedback for all those incoming developments. None of them (except the solR
>> one) has started, so if you want to give us an advice, add something, ...
>> it's now or it may be too late ;-)
>>
>>
> As a vendor-neutral voice, I would like to encourage everyone who has an
> vested interest in these areas and the best interests of the Koha project at
> heart to actively participate and respond to these RFC's. It seems that
> often there is little dicussion, etc. on RFCs in the community. And even
> when there is discussion, etc. it is often unclear if a consensus is reached
> (at least publicly).
>
> Furthermore, I would encourage vendors and others who post RFC's to do so
> with a willingness to adapt, adjust, bend, compromise, and/or
> <your-favorite-term-goes-here> to positions on those RFC's which may be
> different but are clearly the consensus of the community at large. Vendors
> may and often do have the resources to implement "what they want," however,
> this is not in the spirit of cooperation which this project so greatly
> depends upon for its success. Clients of vendors should be educated during
> the RFQ process as to this aspect of open source, and their expectations
> managed accordingly, imho.
>
> I would also suggest that we implement a policy that states in some
> agreeable way that code/features will not be pushed to master which have not
> passed through a review and consensus process by the community and the RM
> (as the elected head of development by the community). No one excepting
> possibly the RM should presuppose that their code is guaranteed inclusion by
> default.
>
> Secondly, I would suggest that we implement a strong recommendation that
> larger shops submit timely RFC's *prior to* beginning work on code and then
> promote discussion on those RFC's. This recommendation should with some
> lesser strength suggest that everyone submit timely RFC's to maximize
> productivity and usefulness of the resources of all concerned.
>
> Thirdly, I would suggest a stated policy (and such a policy is presently in
> place practically) which requires all submissions to pass through a QA
> branch and receive at a minimum one sign-off prior to being pushed into
> master. This policy should also assign a certain amount of responsibility to
> the one signing off to avoid "frivolous" sign-offs. It should also, perhaps,
> include a restriction that the required sign-off for pushing to master be a
> disinterested developer perhaps from another vendor or the community at
> large.
>
> This is a discussion we need to have. I would encourage everyone to invest
> time (the operative term here is 'invest') in this discussion.
>
> Kind Regards,
> Chris Nighswonger
> Koha 3.2.x Release Maintainer
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/4187d531/attachment.htm>