Le Thu, 8 Sep 2016 12:24:02 +0200 (CEST) Alexandre Delaunay <adelau...@teclib.com> a écrit:
>Thanks for your message and suggestions. >I really appreciate. > >For most of theses points, i agree. >- For systematic PR, we could add this process quickly. It concerns a >few developers (mainly me, but also Walid, Yllen & Remi). We pushed >directly to master for convenience. Also, number of external >contributions for fixes issues are not very common. We could add this >process after 9.1 release. It will be more easy and you need only a >few weeks to wait. Ok, not really see why wait but why not :p >- For pull requests linked to issues, it's already the case, most of >the time (you'll certainly find some existing exceptions). > All features was never pushed directly to master (only bugfixes), > and for major ones, issues existed months before work started. Some > with specs, other not, i agree we could enhance this part. I recently > add new feature issues i'd like to see in the the next release. See > "candidate for next version" milestone. It's not a freezed list. ok >- For code review, i could agree, if we had more implications. At the >moment, existing issues and pr are most of the time >read/reviewed/fixed only by me and yllen. So we will not wait a review >for weeks/months (days is acceptable). The main problem actually is >the issue management. You couldn't ask for more reviews if only a few >developers actually do the job. If we have more reviews, i don't have >any objections to add this process. Like we are all in IRC, a dev push a Pull Request can ping another dev to review the code ;) >- Ok for unit tests and travis. It's a rather recent topic, so we >couldn't do it previously, but your suggestion is the next step, so ok. > >- For RC releases, i disagree, we had (for this release by the way) a >lot of feedback. I appreciated this fact. I did mistakes for last >ones. I apologize for that. I'll make more efforts to avoid futures >errors. It's not an excuse, but exhaustion is the main reason. You're right :p >For CS mentioned by jcwi, i don't have a definite opinion. >Change rules to PSR should be a good point but it's a big work. I'm agree with jcwi, it's a big work but it's more simple to check code style. At the end, we win in readable code and perhaps too more simple for external contributions >For git flow, same, if we have a consensus on this tool, ok. >I personally think it's a bit complex. Yes it's complex, in most cases, people use part of it >On the past year, your opinions are also welcome. >I think we missed things but we also added some good enhancements. >My first objective is the enhancement of the projet for all (dev and >users). Like all of us ;) Thanks David ++ >Alexandre. > >----- Mail original ----- >> De: "Johan Cwiklinski" <jcwiklin...@teclib.com> >> À: "Liste de diffusion des developpeurs GLPI" <glpi-dev@gna.org> >> Envoyé: Jeudi 8 Septembre 2016 11:17:45 >> Objet: Re: [Glpi-dev] Modify coding methods to enhance code quality >> >> Hello, >> >> > I propose new coding methods to enhance GLPI (better code, have >> > tests, so less bugs): >> > [...] >> >> Two points I'd like to talk about :) >> >> 1- >> And what about a clear GIT worflow? >> >> For some projects, I've already used git-flow >> (http://nvie.com/posts/a-successful-git-branching-model/); mainly >> because 1/ it suits my needs, and 2/ it comes with a git extension >> that makes things (really much) simple. >> >> Maybe this one would no fit GLPI's needs in terms of worflow (mainly >> because it does not handle long term support branches - ie. only one >> stable version could be maintained); but I guess we should adopt at >> least some workflow rules. >> >> 2- >> Coding standards has not been mentionned yet (if I remember well); >> but their respects could be added to the "contribution guide". >> Standardized code is more simple to read, understand and use :) >> Unfortunately, the rules that have been used until now are very >> specific (it is not PSR1, and even less PSR2, nor any existing >> standard provided with phpcs as fas as I can see). To automate CS >> checks, we'll have to either: >> - write a specfifc ruleset that suits our needs (a quite big >> specific work), >> - or change them to use something existing, that we could adapt for >> our needs finally (forcing all functions or methods to be correctly >> documented for example). That would be a quite big job as well, but >> less specific for instance. >> >> Actual coding standards are documented here: >> https://forge.glpi-project.org/projects/glpi/wiki/CodingStandards >> >> Regards, >> -- >> Johan >> >> _______________________________________________ >> 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
