Re: PEAR2 Coding Standards RFC
| From: | Travis Swicegood | Date: | Tue, 04 Sep 2007 13:23:24 +0000 |
| Subject: | Re: PEAR2 Coding Standards RFC | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-47919@lists.php.net to get a copy of this message | ||
Two quick notes:
1. Logins at the wiki still don't work. Not being able to login and/or register for an account kind of defeats the purpose of a wiki.
2. You can't indent unordered lists in Mediawiki; they need to be flush or they're considered pre-formatted text.
The rest of the comments are inline...
On Sep 3, 2007, at 11:51 PM, Gregory Beaver wrote:
Alan Knowles wrote:I'm for the tests, though I'm partial to them to the point I consider correctly written tests more important than documentation. Documentation can be gleaned later from tests that properly convey what's happening while the reverse isn't always true. I would like to remain test framework agnostic, however. Has any thought been given to this? Some people prefer PHPUnit, while others prefer Simpletest, and yet other phpt. Requiring one specific type may be a put off when they all have the same end-goal.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.
One possible direction is that a few developers who are particularly passionate about their collective could produce a bunch of really great code because they're able to just code... :-) We can hope, no? -TravisSometimes 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.