2014-02-24 17:54 GMT+01:00 Destailleur Laurent <address@hidden>:
2014-02-24 16:24 GMT+01:00 Doursenaud, Raphaël <address@hidden>:
Indeed, this is an important reminder.I'm guilty as much as anyone of working on new features without fixing enough broken code.But, as you may know, it's relatively easy to get paid for working on new features while it's nearly impossible for bug fixing..On the other hand, the Dolibarr codebase suffer from an old and intricate coding structure that don't help fixing bugs efficiently and keeping them that way.We already prooved that making fix with dolibarr need 3 times less times than any other projects using more complex coding structure. I don't think this is the reason.IMHO, even before squashing bugs, it needs a big overhaul of its internal structure.From the top of my head, here are the issues I'm constantly fighting with :
- Inconsistent coding style (cf. Florian post)
Code is fully compliant with our PSR (see answer I made to florian). 100% of checkstyle check of our PSR is success.PSR of dolibarr is described into wiki documentation.
- Relatively Inefficient bug tracker. (Personal opinion)
I am happy with bug tracker. But if you can suggest best thing, it is welcome.
- Classes inconsistency and missing a lot of utility methods. (See next point)
Sure, we can enhance this
- Duplicated code all over the place that should be factored into the native objects. This makes maintenance a nightmare.
Sure, we should enhance this.
- Inconsistent API with half french naming and all.
Sure, we must enhance this.
- Not using parameterized queries and field tested database drivers such as PDO.
We are already using database abstract layer that is 10time better than PDO. We forget PDO a long time ago (it was first choice done) because it was not enough powerfull for us. There was already a lot of exchange on this. We don't need PDO. PDO is not enough powerfull for us, our database abstract layer is really great making dolibarr the only project that provide technical upgrade possible by end users with no technical knowledge and with no need to think to database. We develop for mysql and it works everywhere, even upgrade process. Also we have a unique error management (not other abstract layer), and we have an automatic inclusion of transaction (not also available with other framework) and more...
- Not using a internationalization/localization toolkit such as gettext
Same than PDO. Get text is not enough powerful/featureful for dolibarr. We have our translation framework that works really better. There was also a lot of exchange to proove this.Currently integration with transifex is 100% complete with automatic sync from transifex so i don't think we need something else. Transifex provide all what we need.
- Legacy libraries with bad design decisions (Yes, I'm looking at you PDF documents)
Can you give more example ?
- I forgot a lot of other issues.
I wanted to keep that discussion for the DevCamp but since I already opened the pandora box, here's my thinking:As you stated, Dolibarr is now a mature piece of software.Since removing code is the best way to reduce bugs, maybe it's time to start a disruptive 4.0 development cycle with ambitious objectives and set everything else on maintenance only mode.Here's what would be my go-to list:
- Unify coding style (PSR preferred here because it's community driven, clearly defined and sees massive adoption).
- Reduce codebase by redesigning objects and nicely factoring existing code.
Sure, welcome.
- Fully embrace OOP and other modern PHP features.
- Parameterized SQL queries and unified database driver (PDO).
See previous answer.
- English only code and comments.
Sure
- Gettext translation support.
See previous answer
- Get rid of legacy libraries.
Sure.
- Break the API, yes, let's break it bad for the greatest good, it's a new release after all.
- HTML5 pages.
All pages are already currently HTML5/CSS3 pages. what do you mean ?
- Document, document and document (With better discussions on API design, code comments…).
Sure, everybody onto the wiki...
- Rolling releases with automatic updates? Ok, maybe it's too much for now!
Euh, yes too much for the moment... ;-)Yes, this is a lot of work but it won't be doing itself if we don't set the goal.Oh, now, I should get back to coding new features I'm being paid for…Good luck...Cheers,2014-02-24 11:59 GMT+01:00 Destailleur Laurent <address@hidden>:
I used a title that may hurt every developer. This is just to be sure everybody read my note ;-)Dolibarr is now a very large success among a very large number of users but also developers.During 3.5 beta and still now, we had received a lot of (too much ?) number of Push request for new feature, but nearly no code to fix bug.80% of request coming from external developers was new feature. Each request to add feature introduce around 2 bugs (this is an average value). This means to keep the bug ratio to same level we nee to spend 66% of code change (PR) to fix bug and 33% of code change (PR) to add new features.Because external submission are 80% of PR (Pull Request) to add new feature, we are far away of this ratio. The only one solution we had to not see the bug rate increase dangerously is to have the core team to work ONLY on bug fixes.This is what happened during all the 3.5 period (so several month). But this means also there is less time to validate "major" pull requests of really intersting new features.So some of you may see their pull request with status "pending" even several month after submitting them. Sorry for that. And after a long time, i will probably have to discard completely this pull request that can't be merged easily. Sorry 2.There is now so many people using Dolibarr, that keeping quality and keeping bug rates under control must be a priority, before adding new feature. But this does not mean we will slow down the increase f new feature. This just means that the conclusion is a strange paradox: if you want to help dolibarr project to increase the number of feature, make priority on bugs fix on old feature !(so bug rate will go down and if bug rate goes down, you will see new feature appears more quickly !)...Does this means Dolibarr popularity is growing too quickly ? May be, but this is a good news, isn't it ?
All this text to finally thanks all guys (core team and others) that helped me to fix bugs during the 3.5 beta ! and just after the release of 3.5. I hope they will understand it is a bug thanks !PS: Well 3.5.1 will be released very soon with result of all fixes...PPS: To find what are opened bugs, just create an account on doliforge.org and go onto this report:
And use the comments of tickets to ask advice on how you can fix a selected bug...
Laurent, Dolibarr main project leader------------------------------------------------------------------------------------Twitter: http://www.twitter.com/eldy10_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Raphaël DoursenaudDirecteur technique (CTO)
Technopole Hélioparc2 avenue du Président Pierre Angot64053 PAU CEDEX 9SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Laurent Destailleur (alias Eldy)------------------------------------------------------------------------------------Social networks of my OpenSource projects:Dolibarr Google+: https://plus.google.com/+DolibarrOrg/Dolibarr Facebook: https://www.facebook.com/dolibarrDolibarr Twitter: http://www.twitter.com/dolibarrAWStats Google+: https://plus.google.com/+AWStatsOrgPoject/AWStats Facebook: https://www.facebook.com/awstats.orgAWStats Twitter: http://www.twitter.com/astats_project
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
Raphaël Doursenaud
Directeur technique (CTO)
+33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10