Re: update on HTML_Template_ReIT proposal

On Fri, 21 Mar 2003 13:01:25 +0300 Alexey Borzov <borz_off@cs.msu.su> wrote: > As the cache feature is "not needed inside ITX", I want to commit a > separate package where it will be "needed", in accordance to PEAR > policy on competitive packages. You like to do thing with your own private point of view. I am against this fork, as far as forks are not allowed in PEAR, and, hopefully, will never be allowed, and this is not a competive package as you try to convince us. I can understand a fork should be considered some weeks ago, as you said it was not possible to provide patch (the facts proove that was possible), but there is absolutely no reason to do it now. And if we allow you to fork a PEAR package and publish it on PEAR, it will be a real (and bad) change, and we can expect more requests like that and just makes PEAR runs in chaos, and certainly you will fork more and more things just because you did not find what *you* want inside a package and the maintainers do not agree with you. But if you still want to work alone, regardless to anybody, there are plenty of scripts hosts around to publish your fork. Anyway, I will wait the decisions of the *members* of the PEAR community to see what to do. I hope they will be against too. That can change the way that most of us feel with PEAR. Let see what happens. In the (worst) case, this fork is accepted, you do not have to use, reference(in any part of your sources, docs, descriptions, whatever) to the"official" IT packages, that will be enough bullshits to have a fork without adding more confusions, call it template_boroff if you like but nothing about IT. And indeed, I will stop contributions to PEAR directly and keep my work only for the package I'm currently maintain, the core, and pearweb, at least for a shot period (until the meeting, which should be usefull to stop bullshits like that). > The second reason is that I want to make some (possibly) BC-breaking > changes to callback functionality. And knowing your attitude towards > backwards compatibility, I'd like to do so without having to deal with > you. BCs break will happen with a php5 version, which will come with a fully compatible C module, using all the new features of php5, this will be numbered as version 2. That makes much sense that breaking BC now, and breaking again in a few weeks/months. pierre