Alan Knowles has an update on the status of the template debate in PEAR. Alan chose to highlight a post by Hans Lellelid. I also had this message flagged for comment.
Hans makes the argument for a tighter vision for PEAR, as well as for an overflow method for packages that don’t fit that vision.
Alan asks if the PEAR group should veto this package?
Lukas Smith offers argument against package redundancy that I can sympathize with.
Because PEAR commits to every package. Thats means if Alan gets run over, Paul dies of old age we are still commited to their packages. Even if they both never go away it still means that the QA team will have to deal with it. It also means that users will have to do alot of research instead of a bit. But I think we have agreed that redundant is bad David?
I wonder if the idea of individual package ownership inhibits the development of a consistent PEAR vision?
I think a Savant veto without an alternate solution to the redundancy that already exists within PEAR will only reinforce the perception of special treatment for the first package on the block.
I think this is a very important debate for PEAR.
Feed
Subscribe to this blog…
One “problem” with the way PEAR works today is it relies purely on volunteers coming forward and proposing something. That probably suits the Open Source model but it might be interesting to experiment with a “most wanted” list: packages that PEAR core team think need doing. With the comes the possibility of doing some research / design up front, in specifying requirements.
What we are doing is a tide rope balance. We are open so that more people are willing to commit to our standards. However the absence of a single entity inside PEAR calling all the shots prevents a totaly coherent library. Then again it might make PEAR stronger overall since we are less like microsoft and more like linux that way, which to me is like the difference between genetic engineering and evolution. While I am drifting off now basically evolution is less susceptible to single mistakes, but genetic engineering has the potential of being very efficient and direct while having the risk to destroy anything it touches if a mistake is made. Hmm wonder if I made clear what I was trying to say. Oh well