This page is written in response to the lies that +Phil Daintree has
written about me, and spread on the internet. Despite years of
searching he has been unable to find anything I have written that is
untrue, and he has had to resort to vague generalities, faked emails,
and badly fabricated screenshots (you can see the joins if you zoom in
using any bit mapped image editor). +Phil Daintree is
welcome to make any comments to these pages, as he has done in the
past. If I agree with what he says I will amend my writings, if I do not
agree I have allowed his comments to stand next to mine so that people
can make their own judgements. I have every confidence in the
intelligence of readers to make a sensible judgement based on the facts.
+Phil Daintree will
not allow me the right of reply to any of the lies he has told about
me. It seems to me significant that he realises that if people see both
sides of the argument they will see through his lies.
As with anything I publish, anybody (except the viagara salesmen) can comment on my blog. I make a public commitment that I will not attempt to forge or censor any posts, as goes on in all the communication channels on webERP. If Phil Daintree wishes to dispute anything in this blog he is free to do so. If I am wrong I will alter my post. I trust in the common sense and intelligence of people to read the facts and to make up their own minds.
WebERP has started to move to a "behind closed doors" development model, whereby most of the code changes don't get pushed out to svn until after a release has been done. For instance the changes made for 4.10 weren't committed to svn until after 4.10 was released and then as one large patch (http://sourceforge.net/p/web-erp/code/5797/). The same has since been done for the 4.10.1 release. So the question is, can this development methodology work in the long term?
Not committing code changes until after a release has been done, was a tactic that Oracle employed with mysql as an attempt to stop any forks (such as mariadb) from using their code until after they had released it (http://www.mysqlperformanceblog.com/2012/08/16/where-to-get-a-bzr-tree-of-the-latest-mysql-releases/), and to make taking those commits harder. It seems the intention was to give Oracle a commercial advantage. Presumably this is also the intention behind Logic Works using this technique for their webERP commits. However eventually Oracle was forced to drop this tactic.
I feel that in the end one of the great advantages that open source development has is the concept of "peer review" where the code can be looked at and reviewed by everybody, thus finding and fixing bugs before it is unleashed as a release for people to use in their businesses.
This was shown when the latest version of webERP was released with two scripts that wouldn't even run due to syntax errors in them, and the release had to be redone with the fixes in them, leading to the embarrassing result of there being two different file releases with the same name.
I think in the end Logic Works will like Oracle be forced to give up this behind closed doors development methodology.
Amendment 15/01/2014 - Phil has since said that he wasn't deliberately holding back committing his work, some of it was out for testing at customers and he didn't consider the rest of it sufficient to warrant a commit until after the release was made. Strange that when the work was committed it contained so many errors, but as I have said many times I want this blog to be a true and accurate record so I include Phil's comments so that all may judge.
Amendment 04/11/2014 - +Phil Daintree persists in denying this despite the evidence against him being so obvious. This is the initial commit Phil did on the 2/2/2013 for the release of 4.10.1 as is shown by the update to the Change.log file "+2/2/13 Version 4.10.1 Released". There then follows 5 commits of bug fixes. Here is a huge commit he did on the 22/2/2013 containing a lot of files that were initially in the 4.10.1 release but not updated to subversion. As can be seen Phil now updates the release date of 4.10.1 to the 22/2/2013, nearly 3 weeks after the first release. Phil has said "these files had been tested for some time on a customers server". However here and here are examples of corrections I made immediately after this huge commit to scripts that wouldn't even run as they contain PHP syntax errors. Not only had they not been tested on a customers server they hadn't even been tested by Phil. Then here we have yet another release of 4.10.1 dated 25/2/2013 23 days after the first release of 4.10.1.
How Phil can persist with his lies in the face of such obvious evidence is a mystery only he can explain.
As with anything I publish, anybody (except the viagara salesmen) can comment on my blog. I make a public commitment that I will not attempt to forge or censor any posts, as goes on in all the communication channels on webERP. If Phil Daintree wishes to dispute anything in this blog he is free to do so. If I am wrong I will alter my post. I trust in the common sense and intelligence of people to read the facts and to make up their own minds.
WebERP has started to move to a "behind closed doors" development model, whereby most of the code changes don't get pushed out to svn until after a release has been done. For instance the changes made for 4.10 weren't committed to svn until after 4.10 was released and then as one large patch (http://sourceforge.net/p/web-erp/code/5797/). The same has since been done for the 4.10.1 release. So the question is, can this development methodology work in the long term?
Not committing code changes until after a release has been done, was a tactic that Oracle employed with mysql as an attempt to stop any forks (such as mariadb) from using their code until after they had released it (http://www.mysqlperformanceblog.com/2012/08/16/where-to-get-a-bzr-tree-of-the-latest-mysql-releases/), and to make taking those commits harder. It seems the intention was to give Oracle a commercial advantage. Presumably this is also the intention behind Logic Works using this technique for their webERP commits. However eventually Oracle was forced to drop this tactic.
I feel that in the end one of the great advantages that open source development has is the concept of "peer review" where the code can be looked at and reviewed by everybody, thus finding and fixing bugs before it is unleashed as a release for people to use in their businesses.
This was shown when the latest version of webERP was released with two scripts that wouldn't even run due to syntax errors in them, and the release had to be redone with the fixes in them, leading to the embarrassing result of there being two different file releases with the same name.
I think in the end Logic Works will like Oracle be forced to give up this behind closed doors development methodology.
Amendment 15/01/2014 - Phil has since said that he wasn't deliberately holding back committing his work, some of it was out for testing at customers and he didn't consider the rest of it sufficient to warrant a commit until after the release was made. Strange that when the work was committed it contained so many errors, but as I have said many times I want this blog to be a true and accurate record so I include Phil's comments so that all may judge.
Amendment 04/11/2014 - +Phil Daintree persists in denying this despite the evidence against him being so obvious. This is the initial commit Phil did on the 2/2/2013 for the release of 4.10.1 as is shown by the update to the Change.log file "+2/2/13 Version 4.10.1 Released". There then follows 5 commits of bug fixes. Here is a huge commit he did on the 22/2/2013 containing a lot of files that were initially in the 4.10.1 release but not updated to subversion. As can be seen Phil now updates the release date of 4.10.1 to the 22/2/2013, nearly 3 weeks after the first release. Phil has said "these files had been tested for some time on a customers server". However here and here are examples of corrections I made immediately after this huge commit to scripts that wouldn't even run as they contain PHP syntax errors. Not only had they not been tested on a customers server they hadn't even been tested by Phil. Then here we have yet another release of 4.10.1 dated 25/2/2013 23 days after the first release of 4.10.1.
How Phil can persist with his lies in the face of such obvious evidence is a mystery only he can explain.
i remember well when programmers using punched cards (80 or 96 columns) keep cards deck not in department but under tables or in bags forcing companies to maintnance contracts with this kind of people. today with all technologie available procedures are the same. this is a mental model and i think we must go to by example. work of right way, clear and honest way! lead by example and lets our nooses and head up, not side nor back!
ReplyDeleteGlad I found this post. It’s really awesome.WebERP has started to move to a "behind closed doors" development model, whereby most of the code changes don't get pushed out to svn until after a release has been done. There are many advantages of web ERP based solution as it is convenient to use.
ReplyDelete