Re: proposal: HTML_Template_ReIT, round 2

From: Date: Thu, 27 Feb 2003 07:06:21 +0000
Subject: Re: proposal: HTML_Template_ReIT, round 2
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-13966@lists.php.net to get a copy of this message
On Thursday, February 27, 2003, at 12:52 AM, Alexey Borzov wrote:
John Luxford wrote:
Sorry, but I've got to say -1 here. It's been said already, but Alexey why not just humour Pierre-Alain and create patches? This is the one thing he's asked for all along.
This is not quite true... Here is his first reaction: http://marc.theaimsgroup.com/?l=pear-dev&m=104497807102446&w=2 http://marc.theaimsgroup.com/?l=pear-dev&m=104497959205266&w=2
I see that feelings could very well be taking precedence over getting things done, and that sucks. We need to move past that though and start with a fresh angle. I personally don't blame and don't care to blame anyone for the extra 200 or so messages in my inbox recently. :) I just want to see IT's issues resolved, and I want to see the result be that your hard work can benefit the IT community like you wanted. So regardless of who's right or wrong, be the grown-up in the situation and with any luck we'll all see some new activity on the IT package.
And as I already said, the main problem is: 1. Pierre-Alain does not have time/desire to maintain his package himself; 2. He does not want to let me work on the package; 3. No one can make him, 'cause he is the Almighty Maintainter.
Oh well. If you can't beat 'em, join 'em. Maybe we should appoint a second maintainer...
What's the use of making patches if no one would bother to apply them?
Let's start with the test suite, which wouldn't require patches to commit. Then let's go from there. That gets your foot in the door -- so to speak -- and paves the way for the rest of your changes. It provides the necessary proof to convince Pierre-Alain that your contributions won't adversely affect any of his users.
All technical details are quite resolvable: 1. I can make 1.0.x releases with bugfixes for trivial bugs; 2. Some more bugs will be fixed only in 2.0 --- the fixes are non-trivial; 3. It is possible to make a "caching" IT a subclass of ITX.
Perfect. Then let's do this in stages, and first get a test suite into IT.
So the problems are not technical, but political in nature. And of course the PEAR community can feel free to hate me for pointing out some political problems. :]
Nobody hates anybody nor blames them for starting anything. We could search the archives for proof and flog the guilty, but I doubt any of us have the time. :) Lux
Who cares if they're large, that's what he has asked for because that's what he feels is easiest for him to integrate into IT. Now I know Alexey has done an awful lot of work on IT in the past months, including a much needed test suite (way to go, btw). Perhaps if a merge was to happen in stages it could happen more peacefully? What if we outlined a series of changes that would gradually take place, for the sake of IT, its users, and both Pierre-Alain's and Alexey's time? Something like this: 1) Add the test suite to IT. Since there wasn't one before, there's no need for patches. Any changes necessary here should be made without thought to the rest of the changes. The test suite should reflect the *intended* behaviour -- strange or not -- of IT. This would also pave the way for proof that the rest of the changes do not break B/C. 2) The changes that fix supposed bugs should go first. These should be small, and patch-able. Whether all these make it or not, that is of course up to Pierre-Alain right now, and assuming they pass the new tests I don't see why they wouldn't be accepted. 3) The larger changes can then be done one-at-a-time, and any changes that Pierre-Alain does not feel should be part of the main IT package can always be integrated via an extended package. That would be a win for everybody. People who don't need caching, for example, or who are content with Cache_Lite or something else, or already wrote their code with another Cache package, don't get the extra unused lines of code, even if it's only 15-30 lines. That's beside the point. Choice is the key here, and we're talking about the *user's* choice. That's what Pierre-Alain's concern is and has to be -- the users of IT. If IT is to remain small and light, then let's do away with any built-in functionality that not everyone wants. Extended packages can easily be loaded when the extra features are wanted. I have no personal problem with caching being in IT, but some do and they happen to be the most vocal users. Other packages have no problems dividing themselves into basic/full, so why can't IT be the same way? That's my view of it, and I'm not even an IT user (at the moment). :) So Pierre-Alain, Alexey, what do you say?
-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
-- John Luxford President and Chief Developer ______________________________ SIMIAN systems Driving Web Content Management ______________________________ web : http://www.simian.ca/ email : lux@simian.ca phone : 204.452.8537

« previous php.pear.dev (#13966) next »