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
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.
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
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
On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans derick@php.net 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
On Tue, 9 Dec 2003 21:12:44 +0100 (CET)
Derick Rethans derick@php.net 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
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
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
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.
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
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.
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
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.
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
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