Re: Alphaworks for PEAR
| From: | Alexander Merz | Date: | Thu, 14 Aug 2003 19:37:02 +0000 |
| Subject: | Re: Alphaworks for PEAR | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-19781@lists.php.net to get a copy of this message | ||
Greg Beaver wrote:
the future. Also, I think it's reasonable to say that nothing older than 6 months should still be alpha, and should be deleted from the alpha repository (if it is not undergoing active development). This Please don't stick to the word 'alpha' in the style the there must be an beta and stable - the 'alpha' refers to 'everything can be changed' here.My intention is a place where you work on stuff without bounding to 'it must become beta... asap'. Ie. lets say Gregs publicweb attribute will never become part of the offical distribution, because we decide them not to make a offical release due to policy/security/political/... reasons. Or another example: Cox refactors the DB core currently, his new code is faster, but then he checks that it doesn't work with MySQL. What now - dropping the stuff? What is with apps which havn't to support MySQL - there would the new core a great benefit. Or Gregs error class propose - it is backward compatible and gives you a lot of power, but it requires more overhead. What is if you have your own server with enough power. I really want to see his class in PEAR, but i must -1 to the class, because it is not mass compatible. Gregs and Cox developments show also another problem: they doing this alone at home, this new stuff isn't avaible through CVS, other developers can't follow there work and giving help. Ie Cox his (not-existing!)MySQL-problem, there is maybe a solution for this problem - but nobody can't fix it, or know that this problem exists because his development isn't public. Alphaworks should be place for in-official/experimental code for *exisiting* Packages, it is dedicated for developing and testing useful code which is stable primary in *special* *situations* - may be some parts of the code goes to a stable release, maybe the whole code can go into a stable release if enough people work on this. But if more the one should work on this, you need CVS. I'm against an explicit timeout, this makes no sense for 'install-all' or Gregs new error class. Code is outdated in Alphaworks, if the maintainer says it, the related Package is orphaned or the code goes to CVS-Dir of the package.