[Koha-devel] Guidelines for Patch Acceptance/Rejection

Chris Nighswonger cnighswonger at foundations.edu
Thu Nov 11 03:52:24 CET 2010


And another for 3.2.x:

All patches which will not apply cleanly to 3.2.x should be ported and
submitted as separate patches marked for 3.2.x. (Hopefully the number of
these sort of patches will be few.)

Kind Regards,
Chris


On Wed, Nov 10, 2010 at 6:35 PM, Chris Cormack <chris at bigballofwax.co.nz>wrote:

> I have a few extra rules for 3.4 also
>
> From here http://wiki.koha-community.org/wiki/Roadmap_to_3.4
>
> All patches should have at least 1 signoff before the Release Manager
> looks at them, (exceptions will be made for trivial patches).
> Preferably 2 signoffs, 1 from the QA manager and 1 from someone else.
> Although 1 from the QA manager will suffice.
>
> All patches should refer to a bug number
>
> Chris
>
> 2010/11/11 Ian Walls <ian.walls at bywatersolutions.com>:
> > Everyone,
> >
> > While there can be no guarantees as to whether a patch will be committed
> > into the Koha codebase, I think in practice there are several
> requirements.
> >  This email is an attempt to identify a few of them, and hopefully start
> a
> > discussion about whether they are truly requirements, and what others
> could
> > possibly be added.
> > 1.  The patch must do what it claims to do, in all commonly-supported
> Koha
> > environments
> > 2.  The patch must not break existing functionality
> > 3.  The patch must apply to the current HEAD of the master branch of the
> > code
> > 4.  The patch must follow the Coding Style Guidelines
> > 5.  The patch must be MARC-flavour agnostic
> > 6.  The patch must contain appropriate copyright information
> > 7.  If a database update is require, the patch must handle the update
> both
> > for new installs and upgrades
> > 8.  If a new feature is added, the patch must include appropriate Help
> > documentation
> > What do people think of these requirements?  Are they reasonable?  Should
> > there be more?  I understand that there may not be any set of
> requirements
> > that's completely sufficient, but if we can identify as many as possible,
> it
> > would make developers lives a bit easier, since we'd all have a better
> idea
> > what is needed for our patches to be committable.
> > Cheers,
> >
> > -Ian
> > --
> > Ian Walls
> > Lead Development Specialist
> > ByWater Solutions
> > Phone # (888) 900-8944
> > http://bywatersolutions.com
> > ian.walls at bywatersolutions.com
> > Twitter: @sekjal
> > _______________________________________________
> > 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/
> >
> _______________________________________________
> 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/20101110/ae6b9e5b/attachment-0001.htm>


More information about the Koha-devel mailing list