On to, 2010-06-03 at 11:38 +1200, Reed Wade wrote:
Chris or Lars may have something to add.
This whole issue of how to structure development processes for Koha is pretty big, and I think it might be good to avoid changing too much too fast. For Koha 3.4, off the top of my head, I would suggest: * automatically measure test coverage for the test suite * reject patches that decrease test coverage * reject patches early for obviously low quality - bad commit messages - too many changes in one patch - automatic test suite does not pass - other things that make it hard for RM to review * keep the master branch always ready to release, as far as possible * possibly discuss changes on koha-devel before they are accepted - might apply only to non-trivial things, in the RM's opinion - discussion might help to find the best way of implementing feature * set up a test machine running the current tip of master - Debian packages would make this easy to update - available to everyone (via the web interface) - easy way to see if things work or not, and if the current version exhibits a bug or not That might all already be too much change, so implementing changes more slowly might be a good idea.