Hello,
I propose new coding methods to enhance GLPI (better code, have
tests, so less bugs):
* NEVER (so no exceptions) commit directly in the repository, always
create Pull Requests
* All Pull Request must be linked with an issue (bugs, features...)
* All issues for features must be discussed and so made specification
of what to do in the issue, with that, the developer will win time
when will code it. The developer must be assigned to the issue
* All Pull Requests must be reviewed by another developer, this review
is needed and check these points:
* Check the code, if it's coherent with the issue, coding standards
* check if there are enough tests (unit, integration). So a Pull
Request NEED HAVE tests, if no test, refure merge and add comment
in it
* verify travis (run tests in travis-ci.org) pass
* Once the PR is reviewed and all is OK, merge it. You DON'T MERGE for
the developper pleasure, you merge because you think it's good for
GLPI and code is good quality.
So yes, you think you will loose time, but if you have less bugs to fix
after because it's verified by unit tests, you win time ;)
Another point, for the release it will be better, you can release
directly or perhaps have one RC. Release process is more simple and
you can release when you want with these methods.
I will do that in many projects (with big code and very few developers)
and we win time, quality of code.
David
++
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
