Re: Re: [metabase-dev] MDB news
| From: | Manuel Lemos | Date: | Sat, 07 Sep 2002 03:16:40 +0000 |
| Subject: | Re: Re: [metabase-dev] MDB news | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-8906@lists.php.net to get a copy of this message | ||
Hello,
On 09/05/2002 06:07 PM, Martin Jansen wrote:
On Thu Sep 05, 2002 at 05:3647PM -0300, Manuel Lemos wrote:Actually the merge was my proposal and Lukas accepted my suggestion to lead the effort.The question is, when will people ever trust my experience and start listening? Maybe when they reach maturity and stop the childish anti-Manuel-Lemos work atitude.I really appreciate the fact that you've allowed Lukas and the others to merge Metabase with PEAR::DB. But it is really not fair of you to
now come up from the dust and again start bashing the PEAR developers:It depends on your point of view. If every time somebody challanges the reasoning of your decisions you consider that is bashing, so that should be bashing for you. To me it is constructive criticism because it provides you opportunity to reflect on the impact of your decisions. If you think you decisions are always right and therefore they should not be challenged, even less by Manuel Lemos, that certainly tells a lot about your maturity.
(a) The reason that you don't see more people contributing to MDB is simply that we don't have the time to focus on one project: I haveWe who? The PEAR elite that keeps leaving out people from contributing? Martin, let's be direct here, you never wanted Metabase to be integrated in PEAR in first place. As far as I can recall, only Stig was in favour. Stop insulting our intelligence. Your claim for the lack of time is just an excuse. If you do not want to participate, don't bother to pretend you ever wanted to.
once thought to start digging into MDB deeper to help out with development. But then I saw that Lukas was doing a good job and some others were helping him, so I didn't see the need to join them. I guess others had the same thought. This has nothing to do with stalling the project.Don't pretend you don't remember when everybody was raising difficulties for the merge to happen, first it was the silly style rules, than it was the claimed performance limitations, all that made Lukas run like crazy after things that even if they were important, they were not prioritary because after 6 months, there are only 2 drivers because Lukas spent an huge amount of time reformatting code as I antecipated that would delay the process and would risk to introduce accidental bugs as it surely happened as we all know just by looking at CVS log.
(b) To your argument concerning Smarty: I guess you got something wrong. We actually decided that Smarty should be equiped with a package.xml file, so that it can be installed via "pear install http://smarty.php.net/foo/Smarty-XXX.tar.gz". This does *not* mean that Smarty will be part of PEAR - it will just be installable via the
So as you can see, we haven't really stepped away from the need for pearification - even premiere league code like Smarty doesn't make it's way into CVS because of this ;-).Which is just a real shame because AFAIK Smarty is the best PHP only templating solution because it is based in smart meta-programming concepts that overcome performance limitations of the tradicional template packages. If anybody had doubts before, now it is clear that you do not want the best to be part of PEAR, all you care is to remain stubborn and force people to waste an unrealistic amount of time reformating their code to your style, as if that is the only style that is right. How many more great packages and great developers do you want to keep our from contributing to PEAR?
PEAR infrastructure. This possibility is open to everyone's code - even to your phpclasses.org code.I have long time planned to provide a self installing package format for PHP Classes. It doesn't seem that PEAR tgz based format is good enough. I am more inclined to adopt RPM because it is a world standard for packaging software. This will still be subject of further study. I would have yet to see PEAR tgz based format evolve up to the capabilities of RPM to consider adopting it.
(c) Personally I don't think that the development process of MDB has anything to do with the "anti-Manuel-Lemos" attitude.This statement proves my point: everything I say, you contradict. -- Regards, Manuel Lemos