Le Fri, 9 Sep 2016 11:32:20 +0200 "nini.lasson" <nini.las...@orange.fr> a écrit:
>Hi David, Hi Nelly, >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. But not need to know all code, because most of features. bug fixes are on part of code. We are many coders, in other of my projects, some are so big as GLPI, we are 2, (3 some times) and no problem with that. For bug fixes, not need to fix it too quickly (in 5 minutes), we need review it to be sure the code fix the bug, so if it's merged next day, it's not a really problem >- 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 we are enough to manage it without problems >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. Yep of course ;) >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). In Pull Request, it's simple to comment on a line of the commit, so that's why use Pull Request mean more simplification on code review and we are more sure code go in repository is checked by another developer, so it's for quality enhancement. >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. Not really agree, coding standard is as important as code, like code documentation, because it's more easier to other developers to read and understand the code. David >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 _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
