Re: proposal: HTML_Template_ReIT, round 2

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 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. What's the use of making patches if no one would bother to apply them? 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. 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. :]

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?