Le Wed, 07 Sep 2016 12:17:29 +0200 Tsmr <t...@thetsmr.fr> a écrit: > > >* NEVER (so no exceptions) commit directly in the repository, >always > create Pull Requests > >Agree for adding feature & Disagree for >minor fixes > >For a simple modification like harmonize display classes >(like <tr class='tab_bg_1'>) for me, creating multiples PR is ponderous >process for minor fixes.
no, NEVER commit directly, ALWAYS create a Pull Request. If the tr is missing in previous Pull Request, the code review is here to say to you you missed add a class xxx in the tr. If it's only the tr, so yes a Pull Request. David ++ >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
