[Glpi-dev] Override global constants during development

2017-04-26 Thread Johan Cwiklinski
Hi all, I've implemented some "facilities" in master branch that you may want to know about... It's not yet documented (will be, when I'll have time). The hack is quite simple: just add a config/local_define.php file in your tree. In this file, you can define GLPI_DEMO_MODE or

[Glpi-dev] Code freeze for 9.1.3

2017-04-26 Thread Johan Cwiklinski
Hello, 9.1.3 release is planned at the end of the week. Code is now freezed, no more commits will reach the 9.1/bugfixes branch until release has been done. This will permit to finalize tests and prepare the release. Have a good day! Regards, -- Johan

[Glpi-dev] GLPI 9.1.2

2017-01-10 Thread Johan Cwiklinski
Hello, We plan to release GLPI 9.1.2 on 2017-01-23. We can continue to fix some bugs, we will freeze the whole process on 1027-01-17 or 2017-01-18 (to keep some time to do some checks and prepare the release). After this date, no more fixes will be merged until release has been tagged (or

[Glpi-dev] A word about the "dark side" of developer doc :)

2016-10-17 Thread Johan Cwiklinski
Hello all, As I've previously talked about; I began to write a developer doc, stored on a github repository, and published on readthedocs. I'll tell you a bit more about my choices regarding this. I've decided to use reStructuredText instead of markdown syntax (but not lateX). Why? Just

Re: [Glpi-dev] Branching rules

2016-10-17 Thread Johan Cwiklinski
Hello, > I think we also need a "Release Manager" ;) > > - create the branch > - tag the version > - create / publish the tarball > - check which commits can go in the branch after a RC. I'm pretty OK with that. > And perhaps we also need a "9.1.1" branch > > So only "critical" remaining bugs

Re: [Glpi-dev] Developer docs

2016-10-05 Thread Johan Cwiklinski
Hello Yllen, > For plugin i had made de doc for name convention and describe a creation > step by step. > It's in french and in 0.84 but it's the same for 9.1 > https://forge.glpi-project.org/projects/plugins/wiki/Fr_CreatePlugin084 Really great, I'll complete/fix what I wrote from your

Re: [Glpi-dev] Developer docs

2016-10-05 Thread Johan Cwiklinski
Hello Yllen, > I have made some change for array and block doc of function Great, thank you very much :) I've fixed a small issue in the "code-block" calls ;) -- Johan ___ Glpi-dev mailing list Glpi-dev@gna.org

[Glpi-dev] Developer docs

2016-10-05 Thread Johan Cwiklinski
(As far as I can see, I sent this mail 2 days ago but it has not been delivered... Excuse me if you receive this twice) Hello all, Some time ago, we've talked here about some workflow and rules for the development of the project. I wrote some lines and put all online. You can see the latest

Re: [Glpi-dev] Eradicate SQL in GLPI

2016-10-03 Thread Johan Cwiklinski
Hello, > https://github.com/glpi-project/docdev/issues/1 Agree :) > - Improve the DBmysqlIterator > > https://github.com/glpi-project/glpi/pull/1096 > > - suport COUNT(*) I had in mind that count(*) is not the best choie for performances reasons. Am I wrong? > Other goal: add

Re: [Glpi-dev] Plugins versions and compatibility

2016-09-28 Thread Johan Cwiklinski
Hello, Thanks for you comments :) > > It's me introduce this version number because in old versions of > > GLPI, a plugin is only compatible with a major version of GLPI. Since > > 0.85, plugins are compatible 0.85 & 0.90. > > > > For example, I have plugins compatible 0.85/0.90 not compatible

[Glpi-dev] Plugins versions and compatibility

2016-09-20 Thread Johan Cwiklinski
Hello all, I was thinking about plugins versions and compatibility... And that sounds like a nightmare to me :) I have questions, and maybe some ideas, here it is. First, some plugins versions contains a GLPi version (like 0.90-1.0); what is the inital goal of that? This version of the plugin

Re: [Glpi-dev] Modify coding methods to enhance code quality

2016-09-09 Thread Johan Cwiklinski
Hello, > A fix cause less problem in PR, the only things will be the test > (enough test or not). > > But an urgent bug fix not mean a release in urgency, so it can be > opened some hours (not some days :p) Agree but anyways, bugfix or not, "urgent" or not ; if the PR is OK and has been

Re: [Glpi-dev] Modify coding methods to enhance code quality

2016-09-09 Thread Johan Cwiklinski
Hello, > For PR adding a feature / changing a behavior, I think we need to keep > it open before merging for some time (1 day ?) so other developpers can > comment it (e.g. https://github.com/glpi-project/glpi/pull/945) OK for me, let's say PR will stay opened one day. ++ -- Johan

Re: [Glpi-dev] Modify coding methods to enhance code quality

2016-09-07 Thread Johan Cwiklinski
Hello, - Mail original - > De: "David DURIEUX" > À: "Liste de diffusion des developpeurs GLPI" > Envoyé: Mercredi 7 Septembre 2016 11:16:46 > Objet: [Glpi-dev] Modify coding methods to enhance code quality > > Hello, > > I propose new coding