[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dolibarr-dev] We need bug fixers, not feature developers !
From: |
Philip Lehmann-Böhm |
Subject: |
Re: [Dolibarr-dev] We need bug fixers, not feature developers ! |
Date: |
Mon, 24 Feb 2014 22:19:32 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
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
>