Everything

php

oci in pecl...

php.internals

Thies C. Arntzen

22 years ago

it was actually my idea to for the oci8 stuff - and have some new
maintainer maintain it in pecl.

i see no valid reason against it. he can start hacking on it (in pecl)
starting today - once he is comfortable with it we'll nuke the ext/oci
and use(link, package) the stuff from pecl.

loosing all history for the 2 files is not a deal at all if you ask me,
as not much has happened to teh code in the last many month.

why do we manage to make a big deal out of everything?

if we get a new maintainer, i'd like him to be able to roll independent
from the main-tree. (also - don't forget - not too many ppls use
oracle, and those who do would be more than happy to get new
features/improvemnt from a new maintainer)


thies

Wez Furlong

22 years ago

> it was actually my idea to for the oci8 stuff - and have some new
> maintainer maintain it in pecl.

Yep, I remember.

> i see no valid reason against it. he can start hacking on it (in pecl)
> starting today - once he is comfortable with it we'll nuke the ext/oci
> and use(link, package) the stuff from pecl.

We can go a little bit further than that; lets move it properly in
CVS and roll a pecl release (1.0), and then Tony can continue
his work in the way that pecl is supposed to be working.

> loosing all history for the 2 files is not a deal at all if you ask me,
> as not much has happened to teh code in the last many month.

> why do we manage to make a big deal out of everything?

I agree; I was surprised that it hadn't actually been
moved properly, but thought that someone else had handled
that (along the same lines as the surprise appearance of
pecl/perl today).

> if we get a new maintainer, i'd like him to be able to roll independent
> from the main-tree. (also - don't forget - not too many ppls use
> oracle, and those who do would be more than happy to get new
> features/improvemnt from a new maintainer)

This is precisely what I want to encourage in PECL.

--Wez.

Pierre-Alain Joye

22 years ago

On Tue, 9 Dec 2003 19:57:52 -0000
"Wez Furlong" <wez@thebrainroom.com> wrote:

> > if we get a new maintainer, i'd like him to be able to roll
> > independent from the main-tree. (also - don't forget - not too many
> > ppls use oracle, and those who do would be more than happy to get
> > new features/improvemnt from a new maintainer)
>
> This is precisely what I want to encourage in PECL.

Fully aggreed (if that count ;) ). I really like the idea to work on
package release basis in preference of "horrible" CVS tags ;).

pierre

Derick Rethans

22 years ago

On Tue, 9 Dec 2003, Pierre-Alain Joye wrote:

> On Tue, 9 Dec 2003 19:57:52 -0000
> "Wez Furlong" <wez@thebrainroom.com> wrote:
>
> > > if we get a new maintainer, i'd like him to be able to roll
> > > independent from the main-tree. (also - don't forget - not too many
> > > ppls use oracle, and those who do would be more than happy to get
> > > new features/improvemnt from a new maintainer)
> >
> > This is precisely what I want to encourage in PECL.
>
> Fully aggreed (if that count ;) ). I really like the idea to work on
> package release basis in preference of "horrible" CVS tags ;).

For this to work pear install <pecl package> needs to work first.
Try "pear install tidy" -> doesn't work, while "pear download tidy"
works fine. And as the pear installer has as much docs as the Zend
engine... I've no time/clue on where to start looking for the problem
;-)

Derick

Pierre-Alain Joye

22 years ago

On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans <derick@php.net> wrote:

> On Tue, 9 Dec 2003, Pierre-Alain Joye wrote:
>
> > On Tue, 9 Dec 2003 19:57:52 -0000
> > "Wez Furlong" <wez@thebrainroom.com> wrote:
> >
> > > > if we get a new maintainer, i'd like him to be able to roll
> > > > independent from the main-tree. (also - don't forget - not too
> > > > many ppls use oracle, and those who do would be more than happy
> > > > to get new features/improvemnt from a new maintainer)
> > >
> > > This is precisely what I want to encourage in PECL.
> >
> > Fully aggreed (if that count ;) ). I really like the idea to work on
> > package release basis in preference of "horrible" CVS tags ;).
>
> For this to work pear install <pecl package> needs to work first.

Tomas and I asked many times the help of internals guys and posted a RFC
for binary packages :). But I missed the install error, damnit :P

> Try "pear install tidy" -> doesn't work, while "pear download tidy"
> works fine.

http://pear.php.net/bugs/ is a good start :-D

> And as the pear installer has as much docs as the Zend
> engine... I've no time/clue on where to start looking for the problem
> ;-)

docs? what's that?

pierre

Pierre-Alain Joye

22 years ago

On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans <derick@php.net> wrote:

> On Tue, 9 Dec 2003, Pierre-Alain Joye wrote:
>
> > On Tue, 9 Dec 2003 19:57:52 -0000
> > "Wez Furlong" <wez@thebrainroom.com> wrote:
> >
> > > > if we get a new maintainer, i'd like him to be able to roll
> > > > independent from the main-tree. (also - don't forget - not too
> > > > many ppls use oracle, and those who do would be more than happy
> > > > to get new features/improvemnt from a new maintainer)
> > >
> > > This is precisely what I want to encourage in PECL.
> >
> > Fully aggreed (if that count ;) ). I really like the idea to work on
> > package release basis in preference of "horrible" CVS tags ;).
>
> For this to work pear install <pecl package> needs to work first.
> Try "pear install tidy" -> doesn't work, while "pear download tidy"
> works fine. And as the pear installer has as much docs as the Zend
> engine... I've no time/clue on where to start looking for the problem
> ;-)

Copy the file php-src/pear/PEAR/Downloader.php to
{pearprefix}/PEAR/Downloader.php.

That should fix this bug until the next release.

hth

pierre

Derick Rethans

22 years ago

On Tue, 9 Dec 2003, Pierre-Alain Joye wrote:

> > For this to work pear install <pecl package> needs to work first.
> > Try "pear install tidy" -> doesn't work, while "pear download tidy"
> > works fine. And as the pear installer has as much docs as the Zend
> > engine... I've no time/clue on where to start looking for the problem
> > ;-)
>
> Copy the file php-src/pear/PEAR/Downloader.php to
> {pearprefix}/PEAR/Downloader.php.
>
> That should fix this bug until the next release.

How would that help when Downloader.php is not even used?:

derick@kossu:/usr/local/lib/php$ grep -r Downloader *
derick@kossu:/usr/local/lib/php$

Derick

Jani Taskinen

22 years ago

On Tue, 9 Dec 2003, Wez Furlong wrote:

>> it was actually my idea to for the oci8 stuff - and have some new
>> maintainer maintain it in pecl.
>
>Yep, I remember.
>
>> i see no valid reason against it. he can start hacking on it (in pecl)
>> starting today - once he is comfortable with it we'll nuke the ext/oci
>> and use(link, package) the stuff from pecl.
>
>We can go a little bit further than that; lets move it properly in
>CVS and roll a pecl release (1.0), and then Tony can continue
>his work in the way that pecl is supposed to be working.

And you're moving us into the support nightmare..
Instead of asking what php version they use, we need
to start asking which possible versions of different
extensions they happen to use, how they compiled them,
etc. etc. etc.

Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
exts and the rest in php-src.

--Jani

Wez Furlong

22 years ago

>     And you're moving us into the support nightmare..
>     Instead of asking what php version they use, we need
>     to start asking which possible versions of different
>     extensions they happen to use, how they compiled them,
>     etc. etc. etc.

The flip side is that we can provide them with a "localized"
(not in the i18n sense!) fix much sooner.

This isn't really a problem as you tend to mark all bug
reports as bogus anyway, and no one else provides support.

>     Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
>     exts and the rest in php-src.

More FUD.

--Wez.

Jani Taskinen

22 years ago

On Tue, 9 Dec 2003, Wez Furlong wrote:

>>     And you're moving us into the support nightmare..
>>     Instead of asking what php version they use, we need
>>     to start asking which possible versions of different
>>     extensions they happen to use, how they compiled them,
>>     etc. etc. etc.
>
>The flip side is that we can provide them with a "localized"
>(not in the i18n sense!) fix much sooner.
>
>This isn't really a problem as you tend to mark all bug
>reports as bogus anyway, and no one else provides support.

Sorry, I forgot, of course the relevant bug categories will
also be moved to http://pecl.php.net/bugs/.

FYI: I don't mark all bug reports as bogus. Only those that are..:)

--Jani

Wez Furlong

22 years ago

> >This isn't really a problem as you tend to mark all bug
> >reports as bogus anyway, and no one else provides support.
>
>     Sorry, I forgot, of course the relevant bug categories will
>     also be moved to http://pecl.php.net/bugs/.
>
>     FYI: I don't mark all bug reports as bogus. Only those that are..:)

Everybody will be happy with PECL then :-)

--Wez.

Ilia A.

22 years ago

On December 9, 2003 03:24 pm, Wez Furlong wrote:

> The flip side is that we can provide them with a "localized"
> (not in the i18n sense!) fix much sooner.

The current snapshot system contains a patched version (after the fix is
applied) within 2 hours at most for source distributions and 4 hours for
win32 distributions.

> This isn't really a problem as you tend to mark all bug
> reports as bogus anyway, and no one else provides support.

I beg to differ, there are plenty of people (not to say that there couldn't be
more ;) ) who handle bugs etc... you need to look no further then the NEWS
file.

I may have misunderstood you, so please correct me if I am wrong, but it seems
are you advocating a system where by modules are compiled as shared. This
approach would open a whole can of worms with users using conflicting module
versions, trying to load same modules more then once and so on. Not only will
this be a headache for the users, but also for the QA/developers who wish to
solve user reported problems. Without a way to determine the exact version of
the module it'd be nearly impossible to determine what code is the user
actually using.

Ilia

Wez Furlong

22 years ago

> > The flip side is that we can provide them with a "localized"
> > (not in the i18n sense!) fix much sooner.
>
> The current snapshot system contains a patched version (after the fix is
> applied) within 2 hours at most for source distributions and 4 hours for
> win32 distributions.

By localized I meant that only the part of the code that the user
was worried about gets the fix; quite often, people don't even want
to try our stable snapshots in case they introduce more bugs.

> > This isn't really a problem as you tend to mark all bug
> > reports as bogus anyway, and no one else provides support.
>
> I beg to differ, there are plenty of people (not to say that there

couldn't be

> more ;) ) who handle bugs etc... you need to look no further then the NEWS
> file.
>
> I may have misunderstood you, so please correct me if I am wrong.

I was using Jani's own brand of humour; I do know just how much
work goes into bug fixing (I've spent many hours of my own time
there too, even though I've not been so prolific in that department
recently).

> but it seems
> are you advocating a system where by modules are compiled as shared.

If the person making the installation wishes it, they can do that now.
I am not advocating a change in our default installation.

> This
> approach would open a whole can of worms with users using conflicting

module

> versions, trying to load same modules more then once and so on.

We have that now; it happens rarely (although more often on windows).

> Not only will
> this be a headache for the users, but also for the QA/developers who wish

to

> solve user reported problems. Without a way to determine the exact version

of

> the module it'd be nearly impossible to determine what code is the user
> actually using.

Modules have a version field, and the pear/pecl installer keeps track
of the installed version.

None of these problems are insurmountable, nor are they terrible, and
none of them will affect anyone doing a default install.

If we worry about everything that might possibly make things slightly
harder to debug, then we shouldn't make any changes to the code, write
no more new features and fix bugs for the rest of eternity.

--Wez.

Stig S. Bakken

22 years ago

On Tue, 2003-12-09 at 21:24, Wez Furlong wrote:

> >     And you're moving us into the support nightmare..
> >     Instead of asking what php version they use, we need
> >     to start asking which possible versions of different
> >     extensions they happen to use, how they compiled them,
> >     etc. etc. etc.
>
> The flip side is that we can provide them with a "localized"
> (not in the i18n sense!) fix much sooner.
>
> This isn't really a problem as you tend to mark all bug
> reports as bogus anyway, and no one else provides support.

IMHO moving extensions to PECL would improve the extension maintainer's
ability to provide support, just because he is able to roll patchlevel
releases only with bug fixes.

- Stig

Stig S. Bakken

22 years ago

On Tue, 2003-12-09 at 21:21, Jani Taskinen wrote:

> On Tue, 9 Dec 2003, Wez Furlong wrote:
>
> >> it was actually my idea to for the oci8 stuff - and have some new
> >> maintainer maintain it in pecl.
> >
> >Yep, I remember.
> >
> >> i see no valid reason against it. he can start hacking on it (in pecl)
> >> starting today - once he is comfortable with it we'll nuke the ext/oci
> >> and use(link, package) the stuff from pecl.
> >
> >We can go a little bit further than that; lets move it properly in
> >CVS and roll a pecl release (1.0), and then Tony can continue
> >his work in the way that pecl is supposed to be working.
>
>     And you're moving us into the support nightmare..
>     Instead of asking what php version they use, we need
>     to start asking which possible versions of different
>     extensions they happen to use, how they compiled them,
>     etc. etc. etc.
>
>     Thanks, but no thanks. Keep PECL as sibe...for the not-so-golden
>     exts and the rest in php-src.

We know which releases of which (pecl) extensions are bundled with each
PHP release.  But to meet this problem, we should ask people to attach a
dump of phpinfo() or phpinfo("extname") and make sure that contains the
necessary information.  At the very least, the extension version number
should be in there, preferably added automatically.  There's a field for
version number in the extension struct.  I recall you supporting me
whole-heartedly on the very same issue back in the 4.1.0 days when the
version info was added, remember?

How people compile the extensions should be clear from that also, at
least just as clear as it is today.

- Stig