Re: [Dolibarr-dev] We need bug fixers, not feature developers !

[Philip Lehmann-Böhm]

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 <address@hidden
> <mailto:address@hidden>>:
> 
> 
> 
> 
>     2014-02-24 16:24 GMT+01:00 Doursenaud, Raphaël
>     <address@hidden <mailto: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 <mailto: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 <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
>             address@hidden <mailto:address@hidden>
>             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
>         address@hidden <mailto: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/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
>     address@hidden <mailto:address@hidden>
>     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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>