Moving to PECL

James Cox

23 years ago

>
> So now that the PEAR framework for bundling extensions is in
> place, I figured I'd start a thread about moving all
> extensions to PECL, and then selectively bundling them from
> PECL (perhaps maintaining physical aliases as well.)
>

I'm +1 on this.. And already offered to move stuff, so one other point on
Sterling's list is extensions that will move, and extensions that will stay
firmly where they are.

-- james

Shane Caraveo

23 years ago

James Cox wrote:

>>So now that the PEAR framework for bundling extensions is in
>>place, I figured I'd start a thread about moving all
>>extensions to PECL, and then selectively bundling them from
>>PECL (perhaps maintaining physical aliases as well.)
>>
>
>
> I'm +1 on this.. And already offered to move stuff, so one other point on
> Sterling's list is extensions that will move, and extensions that will stay
> firmly where they are.
>
>  -- james

All extensions should move.  Outside of ext/standard and maybe one or
two others, there is nothing that could not benefit from the possibility
of a seperate release cycle.  With the bundle capability, and cvs
linkage, there should be no ill effect on developers or installation by
making that move.

Shane

(Marcus Börger)

23 years ago

Hello Sterling,

Saturday, June 7, 2003, 7:15:23 PM, you wrote:

SH> Hi,

SH> So now that the PEAR framework for bundling extensions is in place, I
SH> figured I'd start a thread about moving all extensions to PECL, and then
SH> selectively bundling them from PECL (perhaps maintaining physical
SH> aliases as well.)

SH> With the new system, when a release is made, the RM simply needs to run
SH> ::

SH> ./bundle-release

SH> In the PHP5 directory.  And the packages are bundled at the last stable
SH> version.  I'm for moving on getting this done asap.  So I guess the
SH> discussion now is:

SH> a) Any last objections?
SH> b) Should any extensions fall within the PHP-QA process?
SH> c) Is there anything I'm missing/that is missing at this point?

SH> -Sterling
SH> --
SH> "I can't give you a brain, so I'll give you a diploma"
SH>     - The Great Oz, The Wizard of Oz


Some extensions like mbstring behave different when not builtin. So
i suggest we find out which theses are and let them in.

Also for extensions like ext/gd i don't see any reason to move them
out of the php main tree.

regards
marcus

--
Best regards,
Marcus                            mailto:helly@php.net

Shane Caraveo

23 years ago

Marcus Börger wrote:

>
>
> Some extensions like mbstring behave different when not builtin. So
> i suggest we find out which theses are and let them in.

Having them in pecl in no way prevents them from being compiled builtin.

> Also for extensions like ext/gd i don't see any reason to move them
> out of the php main tree.

Release cycles and QA, which is the only reason to do any of this at all.

Shane

Moriyoshi Koizumi

23 years ago

Hi,

Shane Caraveo <shane@caraveo.com> wrote:

> Marcus Börger wrote:
> >
> >
> > Some extensions like mbstring behave different when not builtin. So
> > i suggest we find out which theses are and let them in.
>
> Having them in pecl in no way prevents them from being compiled builtin.

I basically agree about this move, and I even think ext/standard needs
kind of restruction. But PECL framework is not mature yet and a smarter
dynamic loading mechanism is needed to fulfill the requirement as mbstring
puts a hook on the SAPI facility. So, I'm -1 for the emigration this time.

Moriyoshi

Edin Kadribasic

23 years ago

On 7 Jun 2003, Sterling Hughes wrote:

> Hi,
>
> So now that the PEAR framework for bundling extensions is in place, I
> figured I'd start a thread about moving all extensions to PECL, and then
> selectively bundling them from PECL (perhaps maintaining physical
> aliases as well.)

-1
I'm strongly against this move. First of all PEAR framework for handling
extensions is nowhere near complete. It has no support for Windows. It has
no notion of what version of PECL package can be built with what version
of PHP. It requires latest and the greatest GNU tools installed on the
system which is rarely true for some commercial Unixes.

If we are going to bundle most of those extensions anyway, removing them
to PECL would directly reduce the quality of the release as most of them
will receive very little testing.

I understand the wish to make the release process more easy, but I'm
afraid that this proposal will achieve exactly to opposite effect. It will
certainly make maintenance of the Windows binary releases much more
difficult.

Edin

md

23 years ago

I have been hearing about a move to PECL.

What is the difference between an extension compiled into libphp4.so
versus and extension in PECL?

Can someone fill me in.

md

Sterling Hughes

23 years ago

What does PEAR's stability on windows 32 systems have anything to do
with it?  This is an internal change.  Meaning, as an end-user, you
won't see any change.  The separation to PECL is purely a release
management thing.

The move to PECL has been agreed upon multiple times.  We can't have the
release manager coordinating all these different extensions at release
time.  Therefore, we decide which extensions to bundle (all of current
cvs + a few PECL extensions, for example), and the release manager
bundles the last stable release.  You also avoid the problem where
people can't commit alpha features to their extension, for fear a
release might be made of them (or a release is made of these alpha
features, which has happened more than once).

Win32 is a non-issue.  We're not talking about debundling anything from
a release at this point.  As for QA, I suggest you look at the archives,
its been discussed multiple times (or at least, I've had this
conversation multiple times. :)

-Sterling

On Sat, 2003-06-07 at 19:22, Edin Kadribasic wrote:

> On 7 Jun 2003, Sterling Hughes wrote:
>
> > Hi,
> >
> > So now that the PEAR framework for bundling extensions is in place, I
> > figured I'd start a thread about moving all extensions to PECL, and then
> > selectively bundling them from PECL (perhaps maintaining physical
> > aliases as well.)
>
> -1
> I'm strongly against this move. First of all PEAR framework for handling
> extensions is nowhere near complete. It has no support for Windows. It has
> no notion of what version of PECL package can be built with what version
> of PHP. It requires latest and the greatest GNU tools installed on the
> system which is rarely true for some commercial Unixes.
>
> If we are going to bundle most of those extensions anyway, removing them
> to PECL would directly reduce the quality of the release as most of them
> will receive very little testing.
>
> I understand the wish to make the release process more easy, but I'm
> afraid that this proposal will achieve exactly to opposite effect. It will
> certainly make maintenance of the Windows binary releases much more
> difficult.
>
> Edin

--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford

Rasmus Lerdorf

23 years ago

The one point on the QA issue is that nobody ever looks through all the
PECL extensions, but we occasionally grep through all the ext/* extensions
to make sure that an API change, or just a simple mistake that we found
does not occur in other extensions.

We need to raise the priority of PECL/* in the hearts and minds of the
developers so that instead of just scanning ext/* we also scan PECL/*.
Getting it out of PEAR and up to its own top-level cvs module is a start.
It really doesn't have anything to do with PEAR and needs to be a lot
closer to the php-dev crowd than the pear-dev crowd.

-Rasmus

On Sun, 8 Jun 2003, Sterling Hughes wrote:

Pierre-Alain Joye

23 years ago

On Sun, 8 Jun 2003 09:23:29 -0700 (PDT)
Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> The one point on the QA issue is that nobody ever looks through all
> the PECL extensions, but we occasionally grep through all the ext/*
> extensions to make sure that an API change, or just a simple mistake
> that we found does not occur in other extensions.

> We need to raise the priority of PECL/* in the hearts and minds of the
> developers so that instead of just scanning ext/* we also scan PECL/*.

Definitively a good thing.

> Getting it out of PEAR and up to its own top-level cvs module is a
> start. It really doesn't have anything to do with PEAR and needs to be
> a lot closer to the php-dev crowd than the pear-dev crowd.

I do not follow you here. Getting PECL out of the pearcvs sounds the
most logical and safe thing to do (permissions management,
visibility,...).

Then I do not think PECL has really nothing to do with PEAR (I'm
talking about the PEAR infrastructure). PEAR is now very stable, but not
full featured. Versionning, package states and binaries installation,
sources packages on non Unix OS are in the TODO. The last two point
really needs contribution from the php developers. We are not far to get
something good for both binaries and win32 build or?

Indeed PECL has to be closer to the php-dev than peardev, from the
current extensions as well as the future extensions proposals.

But I will not like to see a abyss between PEAR and PECL, as I can see
one between PEAR and php, that will be a *real* pain to maintain the
pear infrastructure and the bundled installer.

my 2cts,

pierre

Sterling Hughes

23 years ago

I agree 100%.

Also, do note that all common extensions will still be direct aliases.
Meaning there should be no difference from a development perspective
(we'll still have the same set of extensions in cvs, for all practical
purposes).  The only difference is that when the release manager goes
ahead and makes a new release, he'll grab the latest stable release from
PECL (which is aliased), instead of using whatever happens to be in CVS.

-Sterling


On Sun, 2003-06-08 at 12:23, Rasmus Lerdorf wrote:

> The one point on the QA issue is that nobody ever looks through all the
> PECL extensions, but we occasionally grep through all the ext/* extensions
> to make sure that an API change, or just a simple mistake that we found
> does not occur in other extensions.
>
> We need to raise the priority of PECL/* in the hearts and minds of the
> developers so that instead of just scanning ext/* we also scan PECL/*.
> Getting it out of PEAR and up to its own top-level cvs module is a start.
> It really doesn't have anything to do with PEAR and needs to be a lot
> closer to the php-dev crowd than the pear-dev crowd.
>
> -Rasmus

--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford

Rasmus Lerdorf

23 years ago

On Sun, 8 Jun 2003, Sterling Hughes wrote:

> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for all practical
> purposes).  The only difference is that when the release manager goes
> ahead and makes a new release, he'll grab the latest stable release from
> PECL (which is aliased), instead of using whatever happens to be in CVS.

But if that is the only motivation here, we don't need to move anything,
we just need developers to tag their extensions when they deem them stable
and makedist simply checks out the latest stable version of the extension.
Problem solved.  You need a better reason for highly disruptive CVS
changes.

-Rasmus

Sebastian Bergmann

23 years ago

Rasmus Lerdorf wrote:

> we just need developers to tag their extensions when they deem them
> stable and makedist simply checks out the latest stable version of
> the extension. Problem solved.

Sounds like a good plan to me as it should solve the problem without
causing trouble.

--
Sebastian Bergmann
http://sebastian-bergmann.de/                 http://phpOpenTracker.de/

http://www.professionelle-softwareentwicklung-mit-php5.de/

Sterling Hughes

23 years ago

On Sun, 2003-06-08 at 12:56, Rasmus Lerdorf wrote:

> On Sun, 8 Jun 2003, Sterling Hughes wrote:
> > I agree 100%.
> >
> > Also, do note that all common extensions will still be direct aliases.
> > Meaning there should be no difference from a development perspective
> > (we'll still have the same set of extensions in cvs, for all practical
> > purposes).  The only difference is that when the release manager goes
> > ahead and makes a new release, he'll grab the latest stable release from
> > PECL (which is aliased), instead of using whatever happens to be in CVS.
>
> But if that is the only motivation here, we don't need to move anything,
> we just need developers to tag their extensions when they deem them stable
> and makedist simply checks out the latest stable version of the extension.
> Problem solved.  You need a better reason for highly disruptive CVS
> changes.
>

Problem not really solved.  First and foremost, managing two branches is
a lot more error prone then just creating a new release.  When you
"only" commit stuff to stable, operations are not entirely atomic and
you don't have proper versioning in place.  In order to achieve a
similair result you would need multiple cvs tags, and the rm would have
to choose the right tag.

This is also the only "current" reason from a "development perspective"
or a "QA perspective."   From a user perspective there are other reasons
as well.  One of the major ones being the ability to go:

]$ pear install mysqli

Because they (or their sysadmin) forgot to compile PHP with mysqli
support.  This only works on UNIX at the moment, but that's 90% of our
userbase that would gain immediate (when PHP5 is released) benefit.
While I think a Win32 port of PEAR/PECL which works as nicely as the
UNIX version is a great idea, its not really a necessity for any of
this.

The Win32 people, as things stand today, not only decide what extensions
get bundled, but they often decide on a different set than what is
bundled with PHP.  Therefore, using PECL, they could even say ::

./build-release win32

And get the standard set of extensions that would be bundled with
win32.  They could further choose extra extensions from PECL, etc. etc.
etc.

The driving idea is that we have a standard distribution and management
point for all extensions.  Its not only for clarity (although that's a
good reason in itself), but it also has practical advantages as well.
Its important that we get the barebones version of this in-place, PECL
needs to become the first class citizen.  Then we can go ahead with some
of the more optimistic goals.

-Sterling

--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford

Rasmus Lerdorf

23 years ago

I know the reasoning, but you were discounting everything except the
versioning which I simply pointed out could be done without the move just
as effectively.  PECL's versioning support is no better than what can be
done directly with CVS.  The pear installer still doesn't work on Windows.
We obviously can't approach it the same was as on UNIX since most Windows
users are not going to have a compiler available.  That means we need to
distribute binaries.  Not a huge hurdle, but some work needs to be done on
this.

We also need to work more on the UNIX pear installer.  For example, take
your zip extension.  Joe Average user who tries to install it sees:

10:27am thinkpad:~> pear install zip
downloading zip-1.0.tgz ...
...done: 4,930 bytes
3 source files, building
running: phpize
PHP Api Version        : 20020918
Zend Module Api No     : 20020429
Zend Extension Api No  : 20021010
building in /var/tmp/pear-build-root/zip-1.0
running: /tmp/tmpaIv3b4/zip-1.0/configure
`/tmp/tmpaIv3b4/zip-1.0/configure' failed

And no info at all on why exactly it failed and that temp build dir is
gone.  We need to keep the configure output in case of failure.  Or even
better, if we could somehow pull the external dependencies from the
config.m4 and add them to the package.xml and have that dependency check
run early on so people got a message right up front that they don't have
the required 3rd party libraries a given PECL package requires.

Of course, a -v reveals:

...
checking for ZIP support... yes, shared
configure: error: Cannot find libzzip
`/tmp/tmp42WFky/zip-1.0/configure' failed

So it makes sense that it failed, but if we pushed this out in its current
state we would spend the next year telling people to add -v and asking for
the output.

Basically my point is that instead of pushing extensions into the current
void that is PECL, we need to pull PECL from the void and make it work
first.  You seem to want to take the reverse approach.  Push everything
into PECL and by doing that force someone to fix it, versus fixing PECL
and then having people fall over themselves trying to get their extensions
into this new brilliant framework.

-Rasmus


On Sun, 8 Jun 2003, Sterling Hughes wrote:

Sterling Hughes

23 years ago

> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first.  You seem to want to take the reverse approach.  Push everything
> into PECL and by doing that force someone to fix it, versus fixing PECL
> and then having people fall over themselves trying to get their extensions
> into this new brilliant framework.

I see it as a hybrid approach.  At this point, PECL has the
infrastructure to support the development portion of the change.  If we
start using it more extensively for such development, then the API
features will come along, and we can start recommending it for end-user
consumption.

I don't think PECL will ever start evolving until we start using it, and
I think its ready for developer usage.

-Sterling

--
"A business that makes nothing but money is a poor kind of business."
- Henry Ford

Edin Kadribasic

23 years ago

On Sun, 8 Jun 2003, Rasmus Lerdorf wrote:

[snip]

> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first.  You seem to want to take the reverse approach.  Push everything
> into PECL and by doing that force someone to fix it, versus fixing PECL
> and then having people fall over themselves trying to get their extensions
> into this new brilliant framework.

This was exactly what I was trying to say. Breaking stuff in hope that it
will force people to fix things afterward instead of making the framework
work first seemed as the wrong approach to take.

Edin

Mike Robinson

23 years ago

It's not like PHP5 will get out the door any time soon. If the plan is
to move all php5 extensions to PECL, why wait? Move them. Fix things.
Seems like a good idea, and fairly straight forward, especially when
you have someone as capable as Sterling volunteering to do the work.

Best Regards
Mike Robinson

(Sorry if I missed something, but this seems like a no-brainer)


Edin Kadribasic wrote:

Tomas V.V.Cox

23 years ago

"Rasmus Lerdorf" <rasmus@lerdorf.com>

> I know the reasoning, but you were discounting everything except the
> versioning which I simply pointed out could be done without the move just
> as effectively.  PECL's versioning support is no better than what can be
> done directly with CVS.

There is already support for: 'alpha','beta','stable','snapsho
t','devel' package states, plus all the version number formats supported by
version_compare(). IMHO that's more than enough.

> The pear installer still doesn't work on Windows.

I you mean the pear installer, it do work on Windows since many time. If you
mean the build of extensions, AFAIR, Shane did it. Take a look at:
php4/pear/PEAR/Builder.php. Don't know if works or not, but the code is
there.

> We also need to work more on the UNIX pear installer.  For example, take
> your zip extension.  Joe Average user who tries to install it sees:

The good news is that even Joe Dumb, could use it.

> 10:27am thinkpad:~> pear install zip
> downloading zip-1.0.tgz ...
> ...done: 4,930 bytes
> 3 source files, building
> running: phpize
> PHP Api Version        : 20020918
> Zend Module Api No     : 20020429
> Zend Extension Api No  : 20021010
> building in /var/tmp/pear-build-root/zip-1.0
> running: /tmp/tmpaIv3b4/zip-1.0/configure
> `/tmp/tmpaIv3b4/zip-1.0/configure' failed
>
> And no info at all on why exactly it failed and that temp build dir is
> gone.  We need to keep the configure output in case of failure.  Or even
> better, if we could somehow pull the external dependencies from the
> config.m4 and add them to the package.xml and have that dependency check
> run early on so people got a message right up front that they don't have
> the required 3rd party libraries a given PECL package requires.

This sounds cool, but perhaps you are not informed on what dependecy
pre-checking PEAR already has (currently: package, extension, program, os,
php version, sapi, zend). External lib checking could be easily implemented
as well.

There is a discussion already at pear-dev on building tools to help
developers the creation of the package.xml file (along other helper tools
like unit tests or api doc generation).

> Of course, a -v reveals:
>
> ...
> checking for ZIP support... yes, shared
> configure: error: Cannot find libzzip
> `/tmp/tmp42WFky/zip-1.0/configure' failed
>
> So it makes sense that it failed, but if we pushed this out in its current
> state we would spend the next year telling people to add -v and asking for
> the output.

Hehe, can't beleive it, you just needed to write pear-dev and I'll commit
the 1 line patch needed to support that.

> Basically my point is that instead of pushing extensions into the current
> void that is PECL, we need to pull PECL from the void and make it work
> first.  You seem to want to take the reverse approach.  Push everything
> into PECL and by doing that force someone to fix it, versus fixing PECL
> and then having people fall over themselves trying to get their extensions
> into this new brilliant framework.

Basically my point is that PECL is not going to have any success or use, if
you don't say what you need for PECL, and first of all: to give it a chance.
We were focusing on PEAR packages because is what we use and because none
told us any feature request or bug report for PECL. The other day, Sterling
came to IRC: "hey Tomas, I need a pear bundle command", in 4 hours he got
it.


Tomas V.V.Cox

Edin Kadribasic

23 years ago

> There is already support for: 'alpha','beta','stable','snapsho
> t','devel' package states, plus all the version number formats supported

by

> version_compare(). IMHO that's more than enough.

Its not. There is now way to tell which PECL extension version works with
which PHP version which is essential and quire easily solvable with CVS
bracnches/tags.

> I you mean the pear installer, it do work on Windows since many time. If

you

> mean the build of extensions, AFAIR, Shane did it. Take a look at:
> php4/pear/PEAR/Builder.php. Don't know if works or not, but the code is
> there.

You cannot ask from people on Windows to have a complete PHP building
environment in order to use PECL extensions.

Edin

Derick Rethans

23 years ago

On Sun, 8 Jun 2003, Rasmus Lerdorf wrote:

> On Sun, 8 Jun 2003, Sterling Hughes wrote:
> > I agree 100%.
> >
> > Also, do note that all common extensions will still be direct aliases.
> > Meaning there should be no difference from a development perspective
> > (we'll still have the same set of extensions in cvs, for all practical
> > purposes).  The only difference is that when the release manager goes
> > ahead and makes a new release, he'll grab the latest stable release from
> > PECL (which is aliased), instead of using whatever happens to be in CVS.
>
> But if that is the only motivation here, we don't need to move anything,
> we just need developers to tag their extensions when they deem them stable
> and makedist simply checks out the latest stable version of the extension.
> Problem solved.  You need a better reason for highly disruptive CVS
> changes.

I kinda agree with this...

Derick

--
"my other box is your windows PC"
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------

John Coggeshall

23 years ago

I was playing around with mysqli and was quite annoyed having to have
both the mysqli and mysql extensions installed in order to have my old
PHP4 scripts working under PHP5.. As one solution, I put together a
script[*] which basically emulates all of the old mysql_* functionality
using strictly mysqli_* functions in user space.

I haven't completely implemented and tested everything yet, but I've
been using it without any problems yet. Is there any interest in having
this bundled with the PHP5 release? If there is I'd be happy to clean it
up and implement the handful of functions which are still unimplemented.

John

* - http://www.coggeshall.org/downloads/mysql2mysqli.tar.gz

--
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org                 http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

Sterling Hughes

23 years ago

You can propose it for PEAR if you like.

-Sterling

On Mon, 2003-06-09 at 08:10, John Coggeshall wrote:

> I was playing around with mysqli and was quite annoyed having to have
> both the mysqli and mysql extensions installed in order to have my old
> PHP4 scripts working under PHP5.. As one solution, I put together a
> script[*] which basically emulates all of the old mysql_* functionality
> using strictly mysqli_* functions in user space.
>
> I haven't completely implemented and tested everything yet, but I've
> been using it without any problems yet. Is there any interest in having
> this bundled with the PHP5 release? If there is I'd be happy to clean it
> up and implement the handful of functions which are still unimplemented.
>
> John
>
> * - http://www.coggeshall.org/downloads/mysql2mysqli.tar.gz
>
> --
> -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
> John Coggeshall
> john at coggeshall dot org                 http://www.coggeshall.org/
> -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-

--
"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg."
- Bjarne Stroustrup

Georg Richter

23 years ago

On Monday 09 June 2003 14:10, John Coggeshall wrote:

Hello John,

> I was playing around with mysqli and was quite annoyed having to have
> both the mysqli and mysql extensions installed in order to have my old
> PHP4 scripts working under PHP5.. As one solution, I put together a
> script[*] which basically emulates all of the old mysql_* functionality
> using strictly mysqli_* functions in user space.

I don't think it's a good idea, it's confusing people:

a) when you need ext/mysql this solution doesn't work.

b) you will have mixed calls mysql_ for the old functions, mysqli for the new
functions. If you want to have mysql_ for all functions, you have to update
it frequently when new functions of functionality comes out.

c) you will run in several problems, when you have functions which became
optional parameters in 4.1, cause you have to support optional parameter link
also.

From my view this solution looks inconsistent.
I think the best solution would be too add a documentation on how to migrate.
For most scripts which work with a default link, this is done in a few
seconds:

$mysql =  mysqli_connect("localhost", "foo", "bar");

then just change mysql_ to $mysql->

$mysql->query("USE foo");

Regards

Georg

Maxim Maletsky

23 years ago

On 08 Jun 2003 12:31:11 -0400
Sterling Hughes <sterling@bumblebury.com> wrote:

> I agree 100%.
>
> Also, do note that all common extensions will still be direct aliases.
> Meaning there should be no difference from a development perspective
> (we'll still have the same set of extensions in cvs, for all practical
> purposes).  The only difference is that when the release manager goes
> ahead and makes a new release, he'll grab the latest stable release from
> PECL (which is aliased), instead of using whatever happens to be in CVS.

+1 on moving to PECL.

It wuold be quite nice separating the developments of the extensions as
these do not always get equally ready for the releases.

--
Maxim Maletsky
maxim@php.net

Per Lundberg

23 years ago

On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:

> Getting it out of PEAR and up to its own top-level cvs module is a start.

+1 on this -- I know myself, when I was trying to find a PECL module
that I *knew* should be somewhere, but I had no idea that it would be
hidden in the PEAR module...

--
Best regards,

Per Lundberg / Capio ApS
Phone: +46-18-4186040
Fax: +46-18-4186049
Web: http://www.nobolt.com

Pierre-Alain Joye

23 years ago

On 10 Jun 2003 11:36:09 +0200
Per Lundberg <per@nobolt.com> wrote:

> On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:
> > Getting it out of PEAR and up to its own top-level cvs module is a
> > start.
>
> +1 on this -- I know myself, when I was trying to find a PECL module
> that I *knew* should be somewhere, but I had no idea that it would be
> hidden in the PEAR module...

That does not change a lot, more a documentation/information problem
;-).

pierre

Martin Jansen

23 years ago

On Tue Jun 10, 2003 at 11:4042AM +0200, Pierre-Alain Joye wrote:

> On 10 Jun 2003 11:36:09 +0200
> Per Lundberg <per@nobolt.com> wrote:
>
> > On Sun, 2003-06-08 at 18:23, Rasmus Lerdorf wrote:
> > > Getting it out of PEAR and up to its own top-level cvs module is a
> > > start.
> >
> > +1 on this -- I know myself, when I was trying to find a PECL module
> > that I *knew* should be somewhere, but I had no idea that it would be
> > hidden in the PEAR module...
>
> That does not change a lot, more a documentation/information problem

Splitting PECL out of PEAR in terms of the website (*) will improve
PECL's position a lot: Right now people consider it to be a subset of
PEAR (the PECL packages are really pretty much hidden in PEAR atm) and
thus don't attach too much importance to it. This is a bad thing since
PECL is one of the coolest things since bread came sliced and it will
(IMO) be very important for the future development of PHP.

(*) As already said before, I don't agree that having a completely
independent website is a good idea. But I actually like James' idea of
pecl.php.net being equivalent (== same machine, same codebase) to
pear.php.net but with a slightly different logo/color scheme and only
showing the PECL packages.

--
- Martin                           Martin Jansen
http://martinjansen.com/

Pierre-Alain Joye

23 years ago

On Tue, 10 Jun 2003 15:37:31 +0200
Martin Jansen <mj@php.net> wrote:

> Splitting PECL out of PEAR in terms of the website (*) will improve
> PECL's position a lot: Right now people consider it to be a subset of
> PEAR (the PECL packages are really pretty much hidden in PEAR atm) and
> thus don't attach too much importance to it. This is a bad thing since
> PECL is one of the coolest things since bread came sliced and it will
> (IMO) be very important for the future development of PHP.

I agree here.

However I would like to increase both PECL and PEAR positions.  Putting
the 2 logos, highlight PECL packages and provide a filter (which can be
automatically set based on the url as you said) may be a good way.

The filter can be in the search/category selects and in the left side
menu.

We fought the past months to put PEAR/PECL in front of the scene, this
should be just another step forward for PEAR/PECL (PECL/PEAR ;), not
only PECL.

pierre

Lukas Smith

23 years ago

Hi,

this is a general reply to what seems to be a theme in this thread. Here
are my observations and comments.

It seems to me that a lot of comment from php-dev people is mostly
concerned about getting control over PECL. I generally agree that
php-dev people have more to do with maintaining the code inside PECL
than the pear-dev people. However there are two parts to PEAR (which
today still includes PECL):

1) code
2) infrastructure

For 1) I think that the php-dev crowd should get really into PECL etc.
But for 2) we should work on a joint effort because it simply makes no
sense to separate the infrastructure. There is too much overlap and also
separating things just makes the user experience worse.

Side note:
1) As far as I know this infrastructure does not depend on having PECL
in side of pearcvs and in order to make code maintenance easier I think
it is very good to move it out of pearcvs.

2) I don't think it's a good idea to let there be too great a difference
in features for windows and *nix. I think we the pear-dev people have
had to deal with a lot of needless user confusion because of the rift in
functionality that was the case in windows and *nix for so long.
Therefore I would much rather like to see that we get the windows
situation (especially in regards to binary distributing) worked out
along with the *nix. Of course we can't magically make compilers appear
on the windows user machines but binary distribution should be
sufficient. So while it is true that moving things to PECL will only
gain *nix folks something and will not take away from the windows crowd
it does create a rift that will create needless confusion imho.

Regards,
Lukas

Georg Richter

23 years ago

On Sunday 08 June 2003 18:23, Rasmus Lerdorf wrote:

> The one point on the QA issue is that nobody ever looks through all the
> PECL extensions, but we occasionally grep through all the ext/* extensions
> to make sure that an API change, or just a simple mistake that we found
> does not occur in other extensions.
>
> We need to raise the priority of PECL/* in the hearts and minds of the
> developers so that instead of just scanning ext/* we also scan PECL/*.
> Getting it out of PEAR and up to its own top-level cvs module is a start.
> It really doesn't have anything to do with PEAR and needs to be a lot
> closer to the php-dev crowd than the pear-dev crowd.

+1

For everyone, developers and users this would be a clear scheme.
Easy to find the stuff you need. As Rasmus said, PEAR and PECL are diffrent
things and should be separated.

Georg

Tomas V.V.Cox

23 years ago

"Georg Richter" <georg@php.net> escribió en el mensaje
news:19QrJS-1tt1xQ0@fmrl00.sul.t-online.com...

> On Sunday 08 June 2003 18:23, Rasmus Lerdorf wrote:
> > The one point on the QA issue is that nobody ever looks through all the
> > PECL extensions, but we occasionally grep through all the ext/*

extensions

> > to make sure that an API change, or just a simple mistake that we found
> > does not occur in other extensions.
> >
> > We need to raise the priority of PECL/* in the hearts and minds of the
> > developers so that instead of just scanning ext/* we also scan PECL/*.
> > Getting it out of PEAR and up to its own top-level cvs module is a

start.

> > It really doesn't have anything to do with PEAR and needs to be a lot
> > closer to the php-dev crowd than the pear-dev crowd.
>
> +1
>
> For everyone, developers and users this would be a clear scheme.
> Easy to find the stuff you need. As Rasmus said, PEAR and PECL are

diffrent

> things and should be separated.
>

Btw, would be nice if some php-developers get involved in the pecl extension
managment of the pear installer as they know pretty much about the real
needs for them. I could write a quick "PEAR installer" doc or answer dubts
about the implementation.


Tomas V.V.Cox

Edin Kadribasic

23 years ago

On 8 Jun 2003, Sterling Hughes wrote:

> What does PEAR's stability on windows 32 systems have anything to do
> with it?  This is an internal change.  Meaning, as an end-user, you
> won't see any change.  The separation to PECL is purely a release
> management thing.
>
> The move to PECL has been agreed upon multiple times.  We can't have the
> release manager coordinating all these different extensions at release
> time.  Therefore, we decide which extensions to bundle (all of current
> cvs + a few PECL extensions, for example), and the release manager
> bundles the last stable release.  You also avoid the problem where
> people can't commit alpha features to their extension, for fear a
> release might be made of them (or a release is made of these alpha
> features, which has happened more than once).

You seem to contradict yourself in the two paragraphs above. We are not
talking about unbundling anything and yet at the same time the release
master decides what extensions to bundle. This can only mean that the
future releases of PHP will contain extensions that recieve less testing
than the ones we have in the release today. Additionally I think that
having different extension set for each release can only bring confussion.

> Win32 is a non-issue.  We're not talking about debundling anything from
> a release at this point.  As for QA, I suggest you look at the archives,
> its been discussed multiple times (or at least, I've had this
> conversation multiple times. :)

I have been a part of this debate for a long time too and I don't remember
that a definitive agreement has been reached beyond a "nice to have in the
future" sort of statement. This move will also IMO introduce more
complexity into already very complex release process.

And Win32 is an issue since there is currently no tool that allows
installation of PECL-only binarries. To sum it all up: nice idea but its
implementation at the present time would create more trouble than its
worth it.

Edin

Sterling Hughes

23 years ago

On Sun, 2003-06-08 at 12:38, Edin Kadribasic wrote:

> On 8 Jun 2003, Sterling Hughes wrote:
>
> > What does PEAR's stability on windows 32 systems have anything to do
> > with it?  This is an internal change.  Meaning, as an end-user, you
> > won't see any change.  The separation to PECL is purely a release
> > management thing.
> >
> > The move to PECL has been agreed upon multiple times.  We can't have the
> > release manager coordinating all these different extensions at release
> > time.  Therefore, we decide which extensions to bundle (all of current
> > cvs + a few PECL extensions, for example), and the release manager
> > bundles the last stable release.  You also avoid the problem where
> > people can't commit alpha features to their extension, for fear a
> > release might be made of them (or a release is made of these alpha
> > features, which has happened more than once).
>
> You seem to contradict yourself in the two paragraphs above. We are not
> talking about unbundling anything and yet at the same time the release
> master decides what extensions to bundle. This can only mean that the
> future releases of PHP will contain extensions that recieve less testing
> than the ones we have in the release today. Additionally I think that
> having different extension set for each release can only bring confussion.
>

Err.  The release manager does:

php5]$ ./bundle-release

Which bundles the stable version of all the extensions we decide belong
in php5.  Whether this list grows our shrinks would require group
concensus, and is not the issue here.

Would you prefer bundling code that is a work in progress?  Currently,
if something goes into cvs, and the author doesn't have time to fix it
before a release, that's what goes into the release.  No matter if it
segfaults, has buffer overruns, leaks, or doesn't compile (although the
latter isn't that common).  With the new system, the developer can
release a stable version of that extension, one that will be bundled,
and go through the "QA" process.  And maintain their cvs version as a
development version of product.

> > Win32 is a non-issue.  We're not talking about debundling anything from
> > a release at this point.  As for QA, I suggest you look at the archives,
> > its been discussed multiple times (or at least, I've had this
> > conversation multiple times. :)
>
> I have been a part of this debate for a long time too and I don't remember
> that a definitive agreement has been reached beyond a "nice to have in the
> future" sort of statement. This move will also IMO introduce more
> complexity into already very complex release process.
>

Right.  Well, that's a concensus.  Everybody agreed that this is the
direction we should go in.  The point of this is to remove that
complexity.

> And Win32 is an issue since there is currently no tool that allows
> installation of PECL-only binarries. To sum it all up: nice idea but its
> implementation at the present time would create more trouble than its
> worth it.
>

On win32, nobody would have to worry about PECL.  As is the situation
today, they would just take the source package that the release manager
made, and make a win32 build from it.  The cvs version of php5 (for
testing) would remain the same.

-Sterling

--
"People can have the Model T in any colour -- so long as it's black."
- Henry Ford

Edin Kadribasic

23 years ago

On 8 Jun 2003, Sterling Hughes wrote:

> php5]$ ./bundle-release
>
> Which bundles the stable version of all the extensions we decide belong
> in php5.  Whether this list grows our shrinks would require group
> concensus, and is not the issue here.
>
> Would you prefer bundling code that is a work in progress?  Currently,
> if something goes into cvs, and the author doesn't have time to fix it
> before a release, that's what goes into the release.  No matter if it
> segfaults, has buffer overruns, leaks, or doesn't compile (although the
> latter isn't that common).  With the new system, the developer can
> release a stable version of that extension, one that will be bundled,
> and go through the "QA" process.  And maintain their cvs version as a
> development version of product.

All of that can be solved with proper CVS versioning. We could have two
branches, HEAD and STABLE, pretty much as we have today except where new
features would be allowed into the STABLE branch after proper testing in
the head.

Currently PECL has no concept of versioning which would only make this
problem even bigger as  today we can use CVS tags and branches to deal
with it. How could I tell which version of openssl extension was bundled
with PHP 5.0.3?

> On win32, nobody would have to worry about PECL.  As is the situation
> today, they would just take the source package that the release manager
> made, and make a win32 build from it.  The cvs version of php5 (for
> testing) would remain the same.

If you move extension into PECL and decide it is not worth bundling with
the main release, people would have no option of getting that extension on
windows unlike the unix folks who could simply say "pear install sqlite".

Edin

Jani Taskinen

23 years ago

On 8 Jun 2003, Sterling Hughes wrote:

>Err.  The release manager does:
>
>php5]$ ./bundle-release
>
>Which bundles the stable version of all the extensions we decide belong
>in php5.  Whether this list grows our shrinks would require group
>concensus, and is not the issue here.

So none of those extensions exist in my cvs checkout before
I run that script? Or what is the idea? To put different
version in place for release than what is in CVS?
What if it doesn't work with current PHP version to
be released? (and Zend)

--Jani

Alan Knowles

23 years ago

Is PECL going to move to the top level in CVS? - it's a bit hidden away
at the moment... (and I guess after these are moved  - creating a 'real'
php5 directory?? - so their's not so many empty directories lying around?)

Regards
Alan


Sterling Hughes wrote:

> Hi,
>
> So now that the PEAR framework for bundling extensions is in place, I
> figured I'd start a thread about moving all extensions to PECL, and then
> selectively bundling them from PECL (perhaps maintaining physical
> aliases as well.)
>
> With the new system, when a release is made, the RM simply needs to run
> ::
>
> ./bundle-release
>
> In the PHP5 directory.  And the packages are bundled at the last stable
> version.  I'm for moving on getting this done asap.  So I guess the
> discussion now is:
>
> a) Any last objections?
> b) Should any extensions fall within the PHP-QA process?
> c) Is there anything I'm missing/that is missing at this point?
>
> -Sterling

--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com

Lukas Smith

23 years ago

> From: Alan Knowles [mailto:alan@akbkhome.com]
> Sent: Sunday, June 08, 2003 4:53 AM

> Is PECL going to move to the top level in CVS? - it's a bit hidden

away

> at the moment... (and I guess after these are moved  - creating a

'real'

> php5 directory?? - so their's not so many empty directories lying

around?)

I am +1 with the move once windows is taken care of.

I am also +1 on moving pecl out of pearcvs.

Regards,
Lukas

James Cox

23 years ago

>
> Is PECL going to move to the top level in CVS? - it's a bit
> hidden away
> at the moment... (and I guess after these are moved  -
> creating a 'real'
> php5 directory?? - so their's not so many empty directories
> lying around?)
>
>

Yes. There are a bunch of cvs admin tasks that I am looking to perform at
some point... These include:

- Moving all of the right ext to pecl.

- Splitting pecl into it's own module

- The possibility of having a separate $CVSROOT for pear/pecl (makes life
more tidy, and we can autogenerate avail... [not that we can't right
now...])

- committing a patch to update all files to the new license

- removing the php5 cvs 'symlink', creating a real php5 module, and
reverting php4/ HEAD from php5-dev to php4-dev (yes, it's only a bugfix tree
now, but we should still be able to cvs co php4 and have a real version...)

- others?

I am throwing this out to internals as I would like to get feedback (and the
anticipated complaining) out of the way before I do it (or not).

-- james

(Marcus Börger)

23 years ago

Hello James,

Sunday, June 8, 2003, 3:42:04 PM, you wrote:

JC>  - Moving all of the right ext to pecl.
JC>  - Splitting pecl into it's own module
JC>  - The possibility of having a separate $CVSROOT for pear/pecl (makes life
JC> more tidy, and we can autogenerate avail... [not that we can't right
JC> now...])
JC>  - committing a patch to update all files to the new license
JC>  - removing the php5 cvs 'symlink', creating a real php5 module, and
JC> reverting php4/ HEAD from php5-dev to php4-dev (yes, it's only a bugfix tree
JC> now, but we should still be able to cvs co php4 and have a real version...)

All sounds fine for me.

marcus