2010/11/10 Chris Cormack <[email protected]> > 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 <[email protected]>: > > 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 > > [email protected] > > Twitter: @sekjal > > _______________________________________________ > > Koha-devel mailing list > > [email protected] > > 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 > [email protected] > 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
_______________________________________________ Koha-devel mailing list [email protected] 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/
