I agree to both points. What I'd love to see for a 4.0 but what would equal a total rewrite: Switching to symfony2 as a foundation.
Am 24.02.2014 19:04, schrieb Doursenaud, Raphaël: > Thanks Laurent for the breakdown and very thorough answer. > I understand most of it but two points I'm particularly interested in > bothers me : > > * SQL parameterization > * i18n/l10n/nls > > I really have a hard time living without SQL parameterization. > Maybe it's because I'm too stubborn and it saved my ass so many times. > The mysqli driver we mainly use allows parameterized queries. > Can't we add a parameterization layer on top of our wonderful > abstraction layer? > > I'm also a bit surprised by your position on PDO, have you had a look at > it lately? > It dramatically improved since its first introduction when it was slow, > buggy and unreliable. > But I can live without it. > > Now on the native language support side of things. > I may be biased by the HUGE number of projects I contributed translation > to that uses gettext or some derivative. > This helped me realize that there is a lot more to it than just swapping > strings off an array. If it was that easy, gettext would not exist. > How do we handle plural forms with our current framework? Did you know > Russian, for example, had 3 plural forms with some complex rules to it I > still fail to understand. > What about words order? Gettext allows placeholders and handles this nicely. > What about date, number, measure and currency formats? > I don't see where Dolibarr translation framework is more powerful here. > Could you give me some pointers? > > Don't even get me started on CJK and RTL support which are way beyond > the scope of this exchange but still has to be introduced sooner or later. > > I'm eager to see your arguments and would love any pointers to old > discussions on the subject. I'm quite new to the community after all… > > Cheers, > > > > 2014-02-24 17:54 GMT+01:00 Destailleur Laurent <[email protected] > <mailto:[email protected]>>: > > > > > 2014-02-24 16:24 GMT+01:00 Doursenaud, Raphaël > <[email protected] <mailto:[email protected]>>: > > 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 > <[email protected] <mailto:[email protected]>>: > > 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 <http://doliforge.org> and go onto this report: > https://doliforge.org/tracker/?atid=246&group_id=144&func=browse > And use the comments of tickets to ask advice on how you can > fix a selected bug... > > > > Laurent, Dolibarr main project leader > > ------------------------------------------------------------------------------------ > Google+: https://plus.google.com/+LaurentDestailleur/ > Facebook: https://www.facebook.com/Destailleur.Laurent > Twitter: http://www.twitter.com/eldy10 > > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > > -- > *Raphaël Doursenaud* > Directeur technique (CTO) > Expert certifié en déploiement Google Apps > > <https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> > +33 (0)5 35 53 97 13 <tel:%2B33%20%280%295%2035%2053%2097%2013> > - +33 (0)6 68 48 20 10 <tel:%2B33%20%280%296%2068%2048%2020%2010> > > <http://gpcsolutions.fr> > http://gpcsolutions.fr > Technopole Hélioparc > 2 avenue du Président Pierre Angot > 64053 PAU CEDEX 9 > SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921 > > <https://www.google.com/a/partnersearch/#partner?partner_id=46687933_a0n60000000sqpWAAQ><http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions> > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] <mailto:[email protected]> > 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/dolibarr > Dolibarr Twitter: http://www.twitter.com/dolibarr > AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ > AWStats Facebook: https://www.facebook.com/awstats.org > AWStats Twitter: http://www.twitter.com/astats_project > > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > > > > > -- > *Raphaël Doursenaud* > Directeur technique (CTO) > Expert certifié en déploiement Google Apps > <https://gpcsolutions.fr/raphael-doursenaud-google-apps-certified-deployment-specialist> > +33 (0)5 35 53 97 13 - +33 (0)6 68 48 20 10 > > <http://gpcsolutions.fr> > http://gpcsolutions.fr > Technopole Hélioparc > 2 avenue du Président Pierre Angot > 64053 PAU CEDEX 9 > SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921 > <https://www.google.com/a/partnersearch/#partner?partner_id=46687933_a0n60000000sqpWAAQ><http://wiki.dolibarr.org/index.php/Dolibarr_suppliers_France#GPC.solutions> > > > _______________________________________________ > Dolibarr-dev mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > _______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
