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.
- 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. - 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. - 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. 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. For git flow, same, if we have a consensus on this tool, ok. I personally think it's a bit complex. 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). 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
