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

[Ian Walls]

Just to throw in on this thread for ByWater Solutions:

It is company policy to obtain at least one signoff from another staff
member before submitting a patch to the community.  We do not anticipate
that this will be sufficient for inclusion into master (except perhaps on
very simple patches), and hope other members of the community will sign off
on our patches.  We will do the same for others in the community as often as
we can.

The end goal of all our development is inclusion into master.  We are
willing to do whatever the Quality Assurance manager and Release Manager
need to make our developments worthy of inclusion (provided we can do so and
still meet our clients' needs).  If this means recoding in a more generic
way, so be it.  All our work is done on separate branches, based off the
current HEAD of master, and rebased/merged as needed to keep it applicable.
 You can see it at http://git.bywatersolutions.com.

It would be helpful to have some kind of general guidelines for inclusion
(i.e. follow the coding style rules, have working unit tests, include
relevant documentation, etc.), even if in the end, it's up to the Release
Manager's expert opinion.  Perhaps this is something we can discuss in an
IRC meeting?

We've started on this (and must continue) to post all our feature ideas on
the wiki.  I'd like those to be public, working "open spec" that anyone is
free to edit and enhance until someone can sponsor all or part of the
feature(s).  Even if no library has the money to pay for the creation of
these features right now, we can all figure out what they'd need to be in
order to meet our needs, worldwide.  Perhaps the unsponsored RFCs can serve
as a rough roadmap for the longterm of Koha (beyond the next release).

I think running a demo site with code that's partially through the Quality
Assurance process, and soliciting librarian feedback would be a good idea,
provided we could actually get librarians to take time to test a system
that's not theirs.

That's all for now.  It's been great meeting so many of you at KohaCon and
the following hackfest.  I look forward to working together with you all to
make 3.4 something great.  Now, off to explore some more of New Zealand
before I have to head home.

Cheers,


-Ian

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

> On Tue, Nov 2, 2010 at 5:57 PM, Paul Poulain <paul.poulain at biblibre.com>wrote:
>
>> Le 02/11/2010 22:27, Paul Poulain a écrit :
>> > SUGGESTIONS TO DISCUSS:
>> > * branch next version when the RM declare feature freeze for a given
>> version
>>
>
> I'll let this one alone for now.
>
>
>> > * have a website rebuilded every night (week ?) (from which branch ? a
>> > waiting_librarian_feedback one ?), with all marc21 default values fitted
>> > in (with maybe a few biblios added), the librarians being requested to
>> > test from a functionnal point of view after the techies QA validation
>>
>>
> I think this is a great idea. If Hudson can do auto builds, surely we can
> setup a server with auto-built test installs for various branches. This
> would have to be limited to some reasonable number, though.
>
> Kind Regards,
> Chris
>
> _______________________________________________
> 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/
>



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101102/ed3cdd9e/attachment.htm>