Hi David,
You have good ideas for GLPI but actually, for me, it's not possible for
many reasons :
- how review the pull request?
For me it's a complete job because you must know very well all
framework of GLPI and we are very few to can do that
and i agree with Olivier: this job must be done regularly in a very
short time for bugs corrections
So this can't do as long as we have a person only affect to this.
- what do you do during holidays?
Developers have rights to be in holidays. So what do you do if you
have a bug to fix and no other dev to check the pull request?
I think the pull request, actually, must only done for all changes and
all changes must are subject to prior discussion with all core developer.
Another point important for me, before to do a commit, you must
imperatively do manually tests (it's boring to have red write after a
commit).
So, all dev must inevitably work in Debug mode.
For unit tests, i totally agree with you and Remi: we don't have enough
tests and all parts can't be tested.
A thing can be done immediately: when you create an issue for a bug,
don't close it after you commit but stay this issue opened until the
return of the request (and, like before, close this issues just before
the release if no return).
Don't forget also coding standard because actually, GLPI is very bad and
in few time, the code will become like before the application of the
coding standard.
Regards,
Yllen
Le 07/09/2016 à 11:16, David DURIEUX a écrit :
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
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
