[Koha-devel] Guidelines for Patch Acceptance/Rejection

[Jesse]

2010/11/10 Chris Cormack <chris at bigballofwax.co.nz>

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

Question for Mr. 3.4 RM:

Is the procedure for dealing with DB revision numbers still the same? As far
as I remember from the 3.2 development days, the procedure was to patch
kohastructure.sql (or sysprefs.sql, or whatever), then add the update to the
end of updatedatabase.pl with a generic version number, like 3.01.00.XXX.
Patching kohastructure.pl was left to the RM when they applied the patch.

I had a crazy table on the wiki for a bit, but this seemed to work better.

That still the consensus?

-- 
Jesse Weaver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101110/d313a8ed/attachment.htm>