Upgrade work methods

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Upgrade work methods

Mickaël PENHARD
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Christophe Battarel

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Mickaël PENHARD
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Sasa Ostrouska


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Mickaël PENHARD
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Jean Traullé
Hello all,

I agree that a slack group or an IRC channel would be great to discuss ;)
Also agree with about everything you said in your first email Mickaël.

In my opinion, it would be great to enforce a coding standard for the project.
This has already been discussed here : https://github.com/Dolibarr/dolibarr/issues/6186
It can be pretty easy with tools like Stickler CI or other static analyzer tools that can be run through CI (Travis or other tools) like phpstan, phan and phpcs.
I continue to think that making exceptions to PSR2 like written in https://wiki.dolibarr.org/index.php/Language_and_development_rules#PHP is not the way to go ...
We just need to clean the code to pass PSR2 for every file and enforce the coding standard to every PR through CI to not reintroduce tabs again.

Another problem is also the growing number of issues not being classified.
An issue is opened here https://github.com/Dolibarr/dolibarr/issues/9306 and it would be great to make progress on that ;)

Jean

Ce message est signé pour en garantir l'authenticité.
Vous pouvez vérifier l'authenticité de ce message (et répondre de façon sécurisée en chiffrant votre réponse) à l'aide de la clé publique attachée à ce message.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 15 janvier 2019 11:09, Mickaël PENHARD <[hidden email]> a écrit :

How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

publickey - jtraulle@opencomp.fr - 0x259843BA.asc (2K) Download Attachment
signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Jean Traullé
After some checks, it seems to be an IRC channel on irc.freenode.net (#dolibarr).

Another thing that crossed my mind is that it would be great to upgrade MediaWiki for wiki.dolibarr.org
I am not really a wiki syntax man and it is really a pain to write/edit pages without the new visual editor that has been introduced since v1.23 (especially tables)
I have done a quick check and all extensions mentioned on https://wiki.dolibarr.org/index.php/Special:Version seems to be in MediaWiki core now so it should be pretty straightforward to upgrade ;)

Let me know what you think ;)

Jean

Ce message est signé pour en garantir l'authenticité.
Vous pouvez vérifier l'authenticité de ce message (et répondre de façon sécurisée en chiffrant votre réponse) à l'aide de la clé publique attachée à ce message.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 15 janvier 2019 11:27, Jean Traullé <[hidden email]> a écrit :

Hello all,

I agree that a slack group or an IRC channel would be great to discuss ;)
Also agree with about everything you said in your first email Mickaël.

In my opinion, it would be great to enforce a coding standard for the project.
This has already been discussed here : https://github.com/Dolibarr/dolibarr/issues/6186
It can be pretty easy with tools like Stickler CI or other static analyzer tools that can be run through CI (Travis or other tools) like phpstan, phan and phpcs.
I continue to think that making exceptions to PSR2 like written in https://wiki.dolibarr.org/index.php/Language_and_development_rules#PHP is not the way to go ...
We just need to clean the code to pass PSR2 for every file and enforce the coding standard to every PR through CI to not reintroduce tabs again.

Another problem is also the growing number of issues not being classified.
An issue is opened here https://github.com/Dolibarr/dolibarr/issues/9306 and it would be great to make progress on that ;)

Jean

Ce message est signé pour en garantir l'authenticité.
Vous pouvez vérifier l'authenticité de ce message (et répondre de façon sécurisée en chiffrant votre réponse) à l'aide de la clé publique attachée à ce message.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le mardi 15 janvier 2019 11:09, Mickaël PENHARD <[hidden email]> a écrit :

How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

publickey - jtraulle@opencomp.fr - 0x259843BA.asc (2K) Download Attachment
signature.asc (523 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Laurent Destailleur (aka Eldy)
In reply to this post by Mickaël PENHARD
Yes, foundation is live. There is a meeting every month as you can see on the link on page that links to all meetings report:

For exchange about coding rules, the current preferred tools is github issues, like any other discussion around the code or features. So thread are public and available to everybody and it is easier to comment, mention, notify, etc than mailing list.
But this works only if we keep 1 issue per point. This is VERY important, chances to have things fixed when there is too many things in same discussion are very low (if issue has too many different point, the issue may be close to avoid chaotic discussions)


Le mar. 15 janv. 2019 à 11:14, Mickaël PENHARD <[hidden email]> a écrit :
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Mickaël PENHARD
Great to know about the foundation,

Does it mandatory to be a part of this foundation to commit on this repository ? What the purpose of it ?
Issue usage is not what we can say something that seem to work as I can see, quite a few about coding style just ignored, to discuss and make sure everybody involved in the development of this software should talk and be agree about what should be done to make it better.
As it's seem you are the main maintainer of this repository, you should engage a way to make us be a part of it, like already said it's seems that there is quite a few people who would like to contribute in a way that it's actually impossible, so all card are in your hand now.

About 1 issue per point which point ? it's all about coding style to let the ability for people to contribute.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:#000000" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 12:06, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :
Yes, foundation is live. There is a meeting every month as you can see on the link on page that links to all meetings report:

For exchange about coding rules, the current preferred tools is github issues, like any other discussion around the code or features. So thread are public and available to everybody and it is easier to comment, mention, notify, etc than mailing list.
But this works only if we keep 1 issue per point. This is VERY important, chances to have things fixed when there is too many things in same discussion are very low (if issue has too many different point, the issue may be close to avoid chaotic discussions)


Le mar. 15 janv. 2019 à 11:14, Mickaël PENHARD <[hidden email]> a écrit :
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Laurent Destailleur (aka Eldy)


Le mer. 16 janv. 2019 à 16:42, Mickaël PENHARD <[hidden email]> a écrit :
Great to know about the foundation,

Does it mandatory to be a part of this foundation to commit on this repository ? What the purpose of it ?

No.
Development is not related to the foundation actions. Development is managed by github process, so everybody can submit feature request and PULL REQUEST to introduce and suggest changes. And everybody can work on it if they think it is a priority or not.

Issue usage is not what we can say something that seem to work as I can see, quite a few about coding style just ignored, to discuss and make sure everybody involved in the development of this software should talk and be agree about what should be done to make it better.

It is you point of view. Most users and developers thinks the opposite. We are currently very happy with this process. We are able to introduce more changes and enhancements with only volunteers than our most important competitors that hire more than hundred of full time developers. So I think it works. Nothing are perfect, but saying it is not efficient is surely not the reality.
 
As it's seem you are the main maintainer of this repository, you should engage a way to make us be a part of it, like already said it's seems that there is quite a few people who would like to contribute in a way that it's actually impossible, so all card are in your hand now.
 
Everybody can be part of it. I am not the maintener, just the guy that merge the work of others. The maintener are everybody that want. The git repository is open to all the world. I suggest you to learn how github, Issues and Pull Request works, it is a very interesting open process. It is difficult to be more open, it is already open to every people on the earth, and for free (creating github account is free).
 

About 1 issue per point which point ? it's all about coding style to let the ability for people to contribute.

Each coding style is 1 point.
You must understand that an issue must contains the "lowest unit of a topic that can't be splitted to be developed independently". If 2 tasks can be done separately, it must be 2 issues. And each coding style rule can be applied independently of the other, so it should be different topics for each of them. You may have your point of view for rule 1 and rule 2, and someone have same point of view than you for coding rule 1 and not coding rule 2. If you have 10 rules, there is 1024 combination of point of view. it is not possible to argue and vote for a suggestion with so many variants.
 

Regards,
Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:rgb(0,0,0)" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 12:06, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :
Yes, foundation is live. There is a meeting every month as you can see on the link on page that links to all meetings report:

For exchange about coding rules, the current preferred tools is github issues, like any other discussion around the code or features. So thread are public and available to everybody and it is easier to comment, mention, notify, etc than mailing list.
But this works only if we keep 1 issue per point. This is VERY important, chances to have things fixed when there is too many things in same discussion are very low (if issue has too many different point, the issue may be close to avoid chaotic discussions)


Le mar. 15 janv. 2019 à 11:14, Mickaël PENHARD <[hidden email]> a écrit :
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net



_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Mickaël PENHARD
About issue, it's not a point of view, it's about usage, I'm using Github on private side quite a lot, issue should be related to real issues, here we are talking about coding style in general, which must be discuss in a global way, not point by point.

Wrong debate about open source world, which is not my goal here to debate on.
And your final answer don't make me feel that you read my first mail entirely ?

The guy who merge work of others, is the maintainer :) and the one which can change the way things are done, so are you open to that ?

Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:#000000" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 17:25, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :


Le mer. 16 janv. 2019 à 16:42, Mickaël PENHARD <[hidden email]> a écrit :
Great to know about the foundation,

Does it mandatory to be a part of this foundation to commit on this repository ? What the purpose of it ?

No.
Development is not related to the foundation actions. Development is managed by github process, so everybody can submit feature request and PULL REQUEST to introduce and suggest changes. And everybody can work on it if they think it is a priority or not.

Issue usage is not what we can say something that seem to work as I can see, quite a few about coding style just ignored, to discuss and make sure everybody involved in the development of this software should talk and be agree about what should be done to make it better.

It is you point of view. Most users and developers thinks the opposite. We are currently very happy with this process. We are able to introduce more changes and enhancements with only volunteers than our most important competitors that hire more than hundred of full time developers. So I think it works. Nothing are perfect, but saying it is not efficient is surely not the reality.
 
As it's seem you are the main maintainer of this repository, you should engage a way to make us be a part of it, like already said it's seems that there is quite a few people who would like to contribute in a way that it's actually impossible, so all card are in your hand now.
 
Everybody can be part of it. I am not the maintener, just the guy that merge the work of others. The maintener are everybody that want. The git repository is open to all the world. I suggest you to learn how github, Issues and Pull Request works, it is a very interesting open process. It is difficult to be more open, it is already open to every people on the earth, and for free (creating github account is free).
 

About 1 issue per point which point ? it's all about coding style to let the ability for people to contribute.

Each coding style is 1 point.
You must understand that an issue must contains the "lowest unit of a topic that can't be splitted to be developed independently". If 2 tasks can be done separately, it must be 2 issues. And each coding style rule can be applied independently of the other, so it should be different topics for each of them. You may have your point of view for rule 1 and rule 2, and someone have same point of view than you for coding rule 1 and not coding rule 2. If you have 10 rules, there is 1024 combination of point of view. it is not possible to argue and vote for a suggestion with so many variants.
 

Regards,
Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:rgb(0,0,0)" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 12:06, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :
Yes, foundation is live. There is a meeting every month as you can see on the link on page that links to all meetings report:

For exchange about coding rules, the current preferred tools is github issues, like any other discussion around the code or features. So thread are public and available to everybody and it is easier to comment, mention, notify, etc than mailing list.
But this works only if we keep 1 issue per point. This is VERY important, chances to have things fixed when there is too many things in same discussion are very low (if issue has too many different point, the issue may be close to avoid chaotic discussions)


Le mar. 15 janv. 2019 à 11:14, Mickaël PENHARD <[hidden email]> a écrit :
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upgrade work methods

Mickaël PENHARD
Someone on the forum launch a meeting call tomorrow 10am.


Mickaël PENHARD
Alvaria SASU - CEO


Le mer. 16 janv. 2019 à 17:42, Mickaël PENHARD <[hidden email]> a écrit :
About issue, it's not a point of view, it's about usage, I'm using Github on private side quite a lot, issue should be related to real issues, here we are talking about coding style in general, which must be discuss in a global way, not point by point.

Wrong debate about open source world, which is not my goal here to debate on.
And your final answer don't make me feel that you read my first mail entirely ?

The guy who merge work of others, is the maintainer :) and the one which can change the way things are done, so are you open to that ?

Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:rgb(0,0,0)" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 17:25, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :


Le mer. 16 janv. 2019 à 16:42, Mickaël PENHARD <[hidden email]> a écrit :
Great to know about the foundation,

Does it mandatory to be a part of this foundation to commit on this repository ? What the purpose of it ?

No.
Development is not related to the foundation actions. Development is managed by github process, so everybody can submit feature request and PULL REQUEST to introduce and suggest changes. And everybody can work on it if they think it is a priority or not.

Issue usage is not what we can say something that seem to work as I can see, quite a few about coding style just ignored, to discuss and make sure everybody involved in the development of this software should talk and be agree about what should be done to make it better.

It is you point of view. Most users and developers thinks the opposite. We are currently very happy with this process. We are able to introduce more changes and enhancements with only volunteers than our most important competitors that hire more than hundred of full time developers. So I think it works. Nothing are perfect, but saying it is not efficient is surely not the reality.
 
As it's seem you are the main maintainer of this repository, you should engage a way to make us be a part of it, like already said it's seems that there is quite a few people who would like to contribute in a way that it's actually impossible, so all card are in your hand now.
 
Everybody can be part of it. I am not the maintener, just the guy that merge the work of others. The maintener are everybody that want. The git repository is open to all the world. I suggest you to learn how github, Issues and Pull Request works, it is a very interesting open process. It is difficult to be more open, it is already open to every people on the earth, and for free (creating github account is free).
 

About 1 issue per point which point ? it's all about coding style to let the ability for people to contribute.

Each coding style is 1 point.
You must understand that an issue must contains the "lowest unit of a topic that can't be splitted to be developed independently". If 2 tasks can be done separately, it must be 2 issues. And each coding style rule can be applied independently of the other, so it should be different topics for each of them. You may have your point of view for rule 1 and rule 2, and someone have same point of view than you for coding rule 1 and not coding rule 2. If you have 10 rules, there is 1024 combination of point of view. it is not possible to argue and vote for a suggestion with so many variants.
 

Regards,
Mickaël PENHARD
Alvaria SASU - CEO
t. <a href="tel:0676202501" style="color:rgb(0,0,0)" target="_blank">06 76 20 25 01   |   e. [hidden email]
a. 21 rue de bel orient, 22600 Loudéac


Le mer. 16 janv. 2019 à 12:06, Laurent Destailleur (aka Eldy) <[hidden email]> a écrit :
Yes, foundation is live. There is a meeting every month as you can see on the link on page that links to all meetings report:

For exchange about coding rules, the current preferred tools is github issues, like any other discussion around the code or features. So thread are public and available to everybody and it is easier to comment, mention, notify, etc than mailing list.
But this works only if we keep 1 issue per point. This is VERY important, chances to have things fixed when there is too many things in same discussion are very low (if issue has too many different point, the issue may be close to avoid chaotic discussions)


Le mar. 15 janv. 2019 à 11:14, Mickaël PENHARD <[hidden email]> a écrit :
How does coders works actually ? I see that it's eldy who make most of the commit history (I suppose the most of the codebase too).
I see quite often message about people who are open to help/contribute, that a good sign, does there is a platform/way to speak about it in live ? Like a slack group, which will be more appropriate in this case because there is a need to discuss a lot about what next will be.

Organization (https://wiki.dolibarr.org/index.php/Statuts_de_l%27association) is still alive ? The last board meeting seem to be from 2013 ?

Regards,

Mickaël PENHARD
Alvaria SASU - CEO


Le lun. 14 janv. 2019 à 21:04, Sasa Ostrouska <[hidden email]> a écrit :


On Mon, Jan 14, 2019 at 6:37 PM Mickaël PENHARD <[hidden email]> wrote:
Hi,

I was thinking to be kind(positive), sorry if it's not interpreted like that.

Regards,
Mickaël PENHARD
Alvaria SASU - CEO

Le lun. 14 janv. 2019 à 18:32, Christophe Battarel <[hidden email]> a écrit :

Thank you Mickaël for sharing your thoughts with us.

I do not know if you have already done it but you should propose your ideas by creating issues and pull requests on github.

And by the way, do not hesitate to be gentle with those who are carrying this great project on their shoulders for years ;-) even if new ideas are always welcome, you should communicate in a more consensual way i think...

Best regards

Christophe


On 14/01/2019 17:31, Mickaël PENHARD wrote:
Hi maintainers,

Are you openminded to change the way you work on this projet ? There is a lot of improvement that can be made, the simplest to begin with is commit, I ask 3 or 4 times already if it's possible to use commit as it should be, but nothing change ?

About commit, it's really a pain to find something and follow upgrade in this context, stop the races version which is absolutely not right, the v1.0.0 it still not available because not all functionally that was suppose to work (base on which is in the wiki, and what is in master version do not do).

Like this commit : 
Why did you put all the garbage of .less/.svg which is not use as I can see in the code, only the compiled css + compiled font is used (like 10 files at max).

Here a simple list :

1. Commit != CTRL+S
2. Commit message should be clear about what it fix/update
3. Stop merge commit on all this versioning ecosystem which not usefull at all
4. Everytime a file is edit, CLEAN IT remove all tabs => space
5. Everytime a function is edit use variable with proper names, not test, thing, object, blabla...
6. Rename table name, all in english, rename inconsistency field example : (facture->facnumber, facture_fourn->ref)
7. Stop any other new development before everything which is available really work, like accountancy
8. It's not possible to refactor (less work to redo everything), but keep old code style clean as much as possible will be a start.
9. I actually manage teamworkers on development projects, and like I said often, let MySQL do the work for you as much as possible, so when you do query like for VAT functions, do the simple math directly in MySQL, all the code of MySQL is reviewed/controlled and each fonction is optimised as much as possible, you will never (or in rare case) bit them on that task, so do it in SQL cleaner/faster :).
10. Avoid sql slit like in accountancy $sql .= .= .= .= use sprintf, or add a function to make format like : https://stackoverflow.com/a/17372566/1891179
11. Avoid multi copy of the same code
12. Wrong usage of jdate( it should be link to sql result object not db object, which make it a pain to use, because of the need to make db instance follow dataset.
13. etc...

Thanks for reading,
Best regards,

Mickaël PENHARD
Alvaria SASU - CEO
 
Hi Mickel, great good points from my point of view. At least on the translate all to english would really be good to see.
Step by step we can come to some of those issues be solved. I am ready to help with. But at the end on an OSS software
project with a lot of people working on it its really difficult to make sure everybody proposes with the same rules his code.

Rgds
Saxa
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


--
------------------------------------------------------------------------------------
Google+: https://plus.google.com/+LaurentDestailleur-Open-Source-Expert/
Facebook: https://www.facebook.com/Destailleur.Laurent
------------------------------------------------------------------------------------
* Dolibarr (Project leader): https://www.dolibarr.org (make a donation for Dolibarr project via Paypal: [hidden email])
* AWStats (Author) : http://awstats.sourceforge.net (make a donation for AWStats project via Paypal: [hidden email])
* AWBot (Author) : http://awbot.sourceforge.net
* CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev