[Koha-devel] BibLibre strategy for Koha 3.4 and next versions

[Lars Wirzenius]

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.