Thinking a bit about this topic, I thought I'd pen some thoughts as to why
bother moving to PECL in the first place, just to put things into
perspective.
As an extension developer, PECL provides the following:
-- your own release cycles.
-- granular package management : want to be the only maintainer? Fine, this
is no problem with PECL. As well as the other sourceforge-esque things that
will come as people request them.
As an end user (and dev), PECL provides the following:
-- easier install path. (# pear install foo)
-- no need to recompile... Useful in hosting environments where you may
have chrooted apache/php..
This doesn't sound like much, however I think it's quite substantial, as it
allows extension developers to provide different release cycles to the main
php core.
What does that mean for the PHP RM?
-- less QA hassle. The only releases that would get sent out via a PHP RM
would be <ext>-<version>-STABLE.tgz -- or in other words, packages that
would have had, theoretically, a substantial amount of QA already, and so
would require less attention from the PHP RM. That means that QA can focus
on core language issues.
-- smaller packages. We can provide php-lite, php-all, php-common packages.
Php-lite would just incorporate the main core of php, and the pear/pecl
tools. Php-all would be a complete bundle, with suggested libraries
included, and php-common would be like php.ini-recommended.
How do we get here?
By moving PECL into the limelight. This week, I will be splitting PECL into
it's own cvs module, and (after discussion) I'd like to create a version of
pearweb for pecl.php.net, essentially seperating the PEAR and PECL projects.
We can then start an upgrade path of getting packages into PECL. I am pretty
sure that doing this kind of stuff will make life easier for our
downstream users (ie, cc'ed Joe Orton, who packages RPMs for RedHat) as they
more or less do this already anyhow. We will (hopefully) make it easier
for them so they can remove their hacks to do this.
I think the feeling of throwing everything into PECL right now is probably
flawed; as Rasmus said, we are at risk of forcing it to be something it's
not right now, and I think this contravenes Stig's excellent management of
PEAR (ie, do it right, don't hack it).
So, the summary:
Lets promote PECL somewhat. Lets make it work without all the minor problems
right now (eg, secure binaries, win32 support, etc etc). Then once we are
all using that instead of recompiles every time.. (which won't take long)
moving to PECL becomes a natural progression.
-- james
James Cox :: james@imajes.info :: http://imajes.info/
Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
The mind leads, the emotions follow. - Ayn Rand
By moving PECL into the limelight. This week, I will be splitting PECL into
it's own cvs module, and (after discussion) I'd like to create a version of
pearweb for pecl.php.net, essentially seperating the PEAR and PECL projects.
While I agree that it's a great idea to make more usage of PECL, I don't
think that the plan to set up pecl.php.net as an independent site will
help us much: It will result in having to maintain yet another site and
fixing bugs in the codebase of pearweb and peclweb (which will be nearly
identical) will eventually turn out to be a nightmare.
Instead I suggest to make pecl.php.net an alias for pear.php.net and
(optically) highlight the PECL packages there, so that interested users
can more easily find them. (I offer to help you doing this.) This way
PECL becomes more visible and we'll only have to maintain one site
instead of two.
--
- Martin Martin Jansen
http://martinjansen.com/
On Mon, 9 Jun 2003 15:16:30 +0100
"James Cox" james@imajes.info wrote:
How do we get here?
By moving PECL into the limelight. This week, I will be splitting PECL
into it's own cvs module, and (after discussion) I'd like to create a
version of pearweb for pecl.php.net, essentially seperating the PEAR
and PECL projects.
I do not agree here with pecl.php.net. From the early days of PEAR, it
contains PEAR and PECL, the roadmaps of PEAR was always to take care of
PECL inside the PEAR infrastructure.
Highlight PECL package inside pear.php.net is quit enough.
As a sidenote, the installer currently does not support multiple master
servers.
Please do not split the whole things, I understand the need of splitting
the cvs tree (even if I still do see all the pros/cons), but why do you
want suddenly get PECL out of PEAR and still use the pear
infrastructure? This is not the way we plan from months now. And I think
we should not got this way. Even if some of the phpdev team actually
discover the pear/pecl is not the siberia and is a nice system :)
So, the summary:
Lets promote PECL somewhat. Lets make it work without all the minor
problems right now (eg, secure binaries, win32 support, etc etc). Then
once we are all using that instead of recompiles every time.. (which
won't take long) moving to PECL becomes a natural progression.
Lets promote the "universal" installer infrastructure used by PECL as
well (and fix/enhance it as said earlier).
pierre
ps: pear's don quichotte :)
On Mon, 9 Jun 2003 15:16:30 +0100
"James Cox" james@imajes.info wrote:How do we get here?
By moving PECL into the limelight. This week, I will be splitting PECL
into it's own cvs module, and (after discussion) I'd like to create a
version of pearweb for pecl.php.net, essentially seperating the PEAR
and PECL projects.I do not agree here with pecl.php.net. From the early days of PEAR, it
contains PEAR and PECL, the roadmaps of PEAR was always to take care of
PECL inside the PEAR infrastructure.
I agree, I go with Markus' aliasing and highlighting thingy.
As a sidenote, the installer currently does not support multiple master
servers.
Fix it! ;)
regards,
Derick
--
"my other box is your windows PC"
Derick Rethans http://derickrethans.nl/
International PHP Magazine http://php-mag.net/