Re: PEAR2 Coding Standards RFC

Alan Knowles wrote: > Looking alot better ;) > > The only bit that stuck out was the "What beta status means" - full > test suite with X% coverage.. - while this is a " would be nice ", I > think you may have removed 80% of existing pear packages by this.. - > perhaps something more simple like, a minimal of example / test code > in docs folder. Test suites prefered... As with the rest of the proposal, I'm happy to hear lots of possible solutions to the "why the hell isn't PEAR more documented and tested" problem, as having 30% documentation and lower test coverage is unacceptable. Currently, we have a new requirement of documentation prior to the "stable" label for all packages in PEAR. Moving this back to "beta" and adding tests would be risky, it's true, but I don't think requiring 1 or 2 examples is a good compromise from requiring full tests. Perhaps others will have some input on this one as well. > - API approval by the borg ;) * This is probably more suited to > larger commonly used packages.. - the smaller ones should have the > API approved before they are voted in on Pepr (although that has > been missed a couple of times) > > I tend to agree with the competing packages rule now.. - I think > filtering proposals through pepr will result in better results with > competing packages... - Although I don't think we are going to ever > solve the abandonware issue that some existing packages have already > become.. I am not fond of PEPr personally in that it requires a lot of up-front commitment, a fair amount of political wrangling, but almost nothing once your package is accepted. The proposal seeks to reverse that, so that projects can be started without much overhead, improved/modified while in alpha form without being publicly available on the website, and the PEPr stage comes when they are ready to be considered mature. The good thing is that since the code never becomes publicly available unless it reaches beta, we can render abandoned alpha projects to the trash heap. Additionally, code that is just not quite ready can be revised in svn.pear.php.net instead of on the developer's home private server, making it easier to fix the problems collaboratively. Much of the abandonware seems to be code that never made it to the minimum requirements of docs + tests. Additionally, abandoned code that does have tests and docs is far easier to take over than code that doesn't. By the way, the PEAR2 code would be on svn.pear.php.net, which we have full control over thanks to Josh, and this makes things much more flexible than they would be through cvs.php.net. The competing rule of "first package is best" seems to have made it a little more difficult to innovate in PEAR if an implementation (i.e. Archive_Tar) is questionable or outdated, and I suspect has led to the "put every feature possible" bloat. By having standard interfaces so that implementations can be interchangeable (as determined by collectives), competing packages are not such a big issue. I have faith that collectives will rule out not-good packages, and will do it with more direct knowledge of the code and the problems it solves than the entire PEAR-wide repository does now. Obviously, packages that really are dramatically different need not have the same interface or API - and shouldn't. > Sometimes I wonder if trying to make a 20 collectives out of ~30 > active developers is really a feasible vision... as I said before, > I'd like to be proved wrong on that one though.... We'll see :). Lots of possible directions. Greg