Hello internals,
I don't see any progress for PHP 6 in the last several months. And we
head more and more into a situation where people no longer develop in
HEAD and instead develop in 5.2 without caring to MFB.
All I know is that we are waiting for the filter extension. As it appears
right now, I do not see Pierre doing the job he offered so we need to find
somebody else here. Anyone care to jump in who has the indepth knowledge?
And besides this filter issue, what are the remaining pieces to be done?
Best regards,
Marcus
And besides this filter issue, what are the remaining pieces to be done?
There's also some work to be done on supporting more of the icu
functionality. It's in progress now.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
There's also some work to be done on supporting more of the icu
functionality. It's in progress now.
Where? Will it be "eat it or die" when you're done?
There've been no replies from core developers to my postings on
php-i18n about providing ResourceBundle API except a single notice
from Andrei.
Regards,
Michael
"Michael Wallner" mike@php.net wrote in message
news:8F.DE.41280.87F2B464@pb1.pair.com...
Where? Will it be "eat it or die" when you're done?
There've been no replies from core developers to my postings on
php-i18n about providing ResourceBundle API except a single notice
from Andrei.
i think i chimed in as well...
there is a post over in i18n from Norbert Lindenberg on the same issue..
l0t3k wrote:
"Michael Wallner" mike@php.net wrote in message
news:8F.DE.41280.87F2B464@pb1.pair.com...Where? Will it be "eat it or die" when you're done?
There've been no replies from core developers to my postings on
php-i18n about providing ResourceBundle API except a single notice
from Andrei.i think i chimed in as well...
You did, but you didn't come back.
there is a post over in i18n from Norbert Lindenberg on the same issue..
I know, I replied that I didn't understand why he wants to create
a new file format. No response--so, it's probably me...
Regards,
Michael
"Michael Wallner" mike@php.net wrote in message
news:DC.12.41280.0B83B464@pb1.pair.com...
l0t3k wrote:
Where? Will it be "eat it or die" when you're done?
There've been no replies from core developers to my postings on
php-i18n about providing ResourceBundle API except a single notice
from Andrei.i think i chimed in as well...
You did, but you didn't come back.
my memory is rusty on this point, but im sure my response was that ICU
ResourceBundles
are cached per-process by locale identifier, so they would cause issues in
mass hosting situations.
way back when, i ripped out the RB code and adapted it specifically for PHP,
but that code was
on a machine that was stolen....
It won't be "eat or die". We're just doing API design and some
prototyping at this point. We'll definitely post info on php-i18n list.
-Andrei
Stanislav Malyshev wrote:
There's also some work to be done on supporting more of the icu
functionality. It's in progress now.Where? Will it be "eat it or die" when you're done?
There've been no replies from core developers to my postings on
php-i18n about providing ResourceBundle API except a single notice
from Andrei.Regards,
Michael
if someone has specific ICU tasks, i can pitch in. i have some (calendar)
locale info fetching code i've been meaning to finish off..
"Stanislav Malyshev" stas@zend.com wrote in message
news:464B2AA2.8000707@zend.com...
And besides this filter issue, what are the remaining pieces to be done?
There's also some work to be done on supporting more of the icu
functionality. It's in progress now.Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Hi Marcus,
for making HEAD the main development branch we should try to reduce the
number of failing tests. Running run-tests.php -n currently still shows
42 tests failing on my current setup. As long as that many tests fail
it's hard to see if a patch breaks anything in there. I recently spent
some time on fixing a few of these tests but there is still enough work
to be done (especially with run-test.php -u ...)
johannes
Hello internals,
I don't see any progress for PHP 6 in the last several months. And we
head more and more into a situation where people no longer develop in
HEAD and instead develop in 5.2 without caring to MFB.All I know is that we are waiting for the filter extension. As it appears
right now, I do not see Pierre doing the job he offered so we need to find
somebody else here. Anyone care to jump in who has the indepth knowledge?And besides this filter issue, what are the remaining pieces to be done?
Best regards,
Marcus
Hello internals,
I don't see any progress for PHP 6 in the last several months. And we
head more and more into a situation where people no longer develop in
HEAD and instead develop in 5.2 without caring to MFB.All I know is that we are waiting for the filter extension. As it appears
right now, I do not see Pierre doing the job he offered so we need to find
somebody else here. Anyone care to jump in who has the indepth knowledge?And besides this filter issue, what are the remaining pieces to be done?
IIRC there were some problems with the streams.
Andrei, please correct me if I'm wrong.
--
Wbr,
Antony Dovgal
Hello internals,
I don't see any progress for PHP 6 in the last several months. And we
head more and more into a situation where people no longer develop in
HEAD and instead develop in 5.2 without caring to MFB.
Please tell these "people" to MFB. Everyone has to MFB or ask for help
if they don't have the time, knowledge or motivation.
All I know is that we are waiting for the filter extension. As it appears
right now, I do not see Pierre doing the job he offered so we need to find
somebody else here. Anyone care to jump in who has the indepth knowledge?
This information is incorrect and misguided, please understand what
you are talking about before making inappropriate claims. Simply
asking me or really any other developer of the filter extension would
have been more productive. I do check my email, and am many times on
IRC.
The filter extension is not holding up PHP 6 except it does not yet
support unicode but that's not the point. Right now all of PHP is
60.56% unicode converted.
And besides this filter issue, what are the remaining pieces to be done?
Now moving on, what you might be referring to is the upcoming input
encoding system (again, nothing to do with ext/filter). We have had
some (very) long discussions about what has to be done, including some
off list, and how to do it. As I remember, there are two people who
are in position to complete this task, both Dmitry and myself but
neither of us have had the time to finish it yet. The JIT at runtime
is done but the input decoding (callback, default values change,
errors, etc.) is not finished.
About the php6 todos in general, I have to take a look again to the
wiki and my todos for the extension I maintain. This long weekend may
be a good opportunity to do some planing.
--Pierre
Hello Pierre,
thanks for the clarification.
best regards
marcus
Wednesday, May 16, 2007, 9:56:25 PM, you wrote:
Hello internals,
I don't see any progress for PHP 6 in the last several months. And we
head more and more into a situation where people no longer develop in
HEAD and instead develop in 5.2 without caring to MFB.
Please tell these "people" to MFB. Everyone has to MFB or ask for help
if they don't have the time, knowledge or motivation.
All I know is that we are waiting for the filter extension. As it appears
right now, I do not see Pierre doing the job he offered so we need to find
somebody else here. Anyone care to jump in who has the indepth knowledge?
This information is incorrect and misguided, please understand what
you are talking about before making inappropriate claims. Simply
asking me or really any other developer of the filter extension would
have been more productive. I do check my email, and am many times on
IRC.
The filter extension is not holding up PHP 6 except it does not yet
support unicode but that's not the point. Right now all of PHP is
60.56% unicode converted.
And besides this filter issue, what are the remaining pieces to be done?
Now moving on, what you might be referring to is the upcoming input
encoding system (again, nothing to do with ext/filter). We have had
some (very) long discussions about what has to be done, including some
off list, and how to do it. As I remember, there are two people who
are in position to complete this task, both Dmitry and myself but
neither of us have had the time to finish it yet. The JIT at runtime
is done but the input decoding (callback, default values change,
errors, etc.) is not finished.
About the php6 todos in general, I have to take a look again to the
wiki and my todos for the extension I maintain. This long weekend may
be a good opportunity to do some planing.
--Pierre
Best regards,
Marcus
This information is incorrect and misguided, please understand what
you are talking about before making inappropriate claims. Simply
asking me or really any other developer of the filter extension would
have been more productive. I do check my email, and am many times on
IRC.
Except you don't seem to reply to any of my emails or IRC chat requests.
The filter extension is not holding up PHP 6 except it does not yet
support unicode but that's not the point. Right now all of PHP is
60.56% unicode converted.
That refers only to the function coverage, not the core functionality.
Now moving on, what you might be referring to is the upcoming input
encoding system (again, nothing to do with ext/filter). We have had
some (very) long discussions about what has to be done, including some
off list, and how to do it. As I remember, there are two people who
are in position to complete this task, both Dmitry and myself but
neither of us have had the time to finish it yet. The JIT at runtime
is done but the input decoding (callback, default values change,
errors, etc.) is not finished.
Correct. Dmitry or I, or possibly Sara, have to finish that.
About the php6 todos in general, I have to take a look again to the
wiki and my todos for the extension I maintain. This long weekend may
be a good opportunity to do some planing.
I would request that you do not try to work on the input decoding
feature since you proved very unreliable in the past.
Best regards,
-Andrei
Hi Andrei.
This information is incorrect and misguided, please understand what
you are talking about before making inappropriate claims. Simply
asking me or really any other developer of the filter extension would
have been more productive. I do check my email, and am many times on
IRC.Except you don't seem to reply to any of my emails or IRC chat requests.
I replied to all mails I got from you. About IRC, sorry, but EFNet's
php channel are really not anymore my cup of tea and I told you that
already. But I'm reachable by email or on freenode, like always.
Now moving on, what you might be referring to is the upcoming input
encoding system (again, nothing to do with ext/filter). We have had
some (very) long discussions about what has to be done, including some
off list, and how to do it. As I remember, there are two people who
are in position to complete this task, both Dmitry and myself but
neither of us have had the time to finish it yet. The JIT at runtime
is done but the input decoding (callback, default values change,
errors, etc.) is not finished.Correct. Dmitry or I, or possibly Sara, have to finish that.
About the php6 todos in general, I have to take a look again to the
wiki and my todos for the extension I maintain. This long weekend may
be a good opportunity to do some planing.I would request that you do not try to work on the input decoding
feature since you proved very unreliable in the past.
I suggest you to change your way to ask things.
You first requested me to give the hand, and that's what I did. And
suddenly, only because one lost the interest/time/motivation to do it,
I was again in charge without any kind of discussion or questions.That
surprises me, but I can live with that. But please, stop to tell me
that I'm not reliable, that's insulting and does not reflect the
facts.
--Pierre
I replied to all mails I got from you. About IRC, sorry, but EFNet's
php channel are really not anymore my cup of tea and I told you that
already. But I'm reachable by email or on freenode, like always.
You did not reply to my emails asking for status on the input
decoding part, more than once.
I would request that you do not try to work on the input decoding
feature since you proved very unreliable in the past.I suggest you to change your way to ask things.
You first requested me to give the hand, and that's what I did. And
suddenly, only because one lost the interest/time/motivation to do it,
I was again in charge without any kind of discussion or questions.That
surprises me, but I can live with that. But please, stop to tell me
that I'm not reliable, that's insulting and does not reflect the
facts.
The facts are these: you signed up to work on the input decoding
feature, knowing full well that it is a critical infrastructure
piece. You told me that you made some progress but also ran into
problems. Over the course of a month or so, I asked multiple times
about the status of this project, both on email and on IRC, and did
not receive a reply from you most of the time. If you lost interest/
time/motivation to do this, you should have said this outright
instead of stringing us along for weeks while you made miscellaneous
patches to GD and zip extensions. At the end, all I was asking for
was the code you had written so far, and even that you were not
willing to share. So yes, I do consider you flaky and unreliable, and
that is my (and some of the others' by the way) personal opinion, but
don't tell me that this does not reflect the facts.
-Andrei
I would request that you do not try to work on the input decoding
feature since you proved very unreliable in the past.I suggest you to change your way to ask things.
You first requested me to give the hand, and that's what I did. And
suddenly, only because one lost the interest/time/motivation to do it,
I was again in charge without any kind of discussion or questions.That
surprises me, but I can live with that. But please, stop to tell me
that I'm not reliable, that's insulting and does not reflect the
facts.The facts are these: you signed up to work on the input decoding
feature, knowing full well that it is a critical infrastructure
piece.
We agree on one thing, It is a critical part. That's why I took so
much time to explain how it could work and why it is important to do
it this way.
You told me that you were working on php6 in the last two or three
years. Why did you not work on that earlier?
You told me that you made some progress but also ran into
problems. Over the course of a month or so, I asked multiple times
about the status of this project, both on email and on IRC, and did
not receive a reply from you most of the time.
Nice, there is progress. It was "never", now it is "most of the
times". Will it be "always" tomorrow?
If you lost interest/
time/motivation to do this, you should have said this outright
instead of stringing us along for weeks
If you played ping-pong with the possible volunteers while trying to
get it sooner than later, you are the only one to blame, face the
truth.
while you made miscellaneous
patches to GD and zip extensions.
And for many other projects, what I do or not during my work day or in
my free time is not your problem. What does that have to do with this
issue? Nothing.
However, to clarify this question, most if not all patches I applied
to the PHP tree in the last months are security fixes or critical bug
fixes.You have to understand that such tasks have a higher priority
than PHP 6.
That being said, you are not in the position to tell me what I have to
do in my free time, in PHP or not, understand that.
At the end, all I was asking for
was the code you had written so far, and even that you were not
willing to share. So yes, I do consider you flaky and unreliable, and
that is my (and some of the others' by the way) personal opinion, but
don't tell me that this does not reflect the facts.
I tell you that it does not reflect the fact and your lack of
objectivity is not funny anymore.Your (selective) memory has holes and
I can't accept such terms to describe what I do for PHP.
But you completely "forgot" to mention that I gave the hand to Sara.
After a couple of weeks and yet another discussions on IRC, I realized
that I was again in charge. Do you really think that you can treat me
like the last wheel of the car and then come back to beg me? You must
be kidding!
Now about what you (or any other) think about me, I cannot care less
but I do not accept personal attacks, I never did. It is simply
unacceptable and respectless.
I do my best for PHP and in my free time. And for what I hear, a lot
of people appreciate my work, many more than you and the 2-3 other
PHP jet setters having troubles with me for all possible reasons.
I provide fixes, new features and improvements in time and every time
it was asked and only in my free time. Consider to be slightly more
respectful and I may consider to work more for php6. But for now and
given the current mess, PHP6 is not my priority. You want something
from me? for a given date? Pay me or be patient.
But Is the PHP development list the right place to discuss our
personal feelings? I don't think so.
Short version:
this discussion is ridiculous. You want something done before a given
date? you have ways to get it, but you cannot push a developer (even
me) like that, especially not when it is a volunteer.
If you have something constructive to say, I will read it carefully
and try to help you. If not, feel free to continue this senseless
discussion, but I have better things to do than reading such
stupidities.
--Pierre
Go take a pill.
-Andrei
P.S. Open Source volunteering still implies a level of commitment.
[deleted]
Go take a pill.
-Andrei
P.S. Open Source volunteering still implies a level of commitment.
As well as respect, something you don't have. But this stupid answer
just made my point. Fine, your problem.
Oh no, you're not my problem anymore.
-Andrei
Go take a pill.
-Andrei
P.S. Open Source volunteering still implies a level of commitment.
As well as respect, something you don't have. But this stupid answer
just made my point. Fine, your problem.
Please, guys, take this argument off list if you want to continue it at all.
The main point Andrei tried to make was lost in that argument. PHP 6 needs
commitment from everybody involved, somewhere along the line, and we all -
even hangers-on like me - need to know that someone will step up to make
filtering possible if we're to believe in PHP 6 ever happening.
Johannes and Tony both made good points. There are still issues with
streams, but more - there are real problems in the way that PHP_5_2 is seen
by many devs as the current development branch.
There needs to be a sitting-back, at some point, and a 'where are we up to?'
moment. Lukas has done his utmost to provide that already, but it hasn't
changed anything that way. I'm still watching commits to PHP_5_2 that are
never merged to HEAD, and not only in ext/pdo.
You still need to beat the Perl 6 release folks ;) but maybe pushing too
hard isn't the way to go about it... I don't know. I just know the
commitment hasn't been made yet for it to happen.
- Steph
----- Original Message -----
From: "Andrei Zmievski" andrei@gravitonic.com
To: "Pierre" pierre.php@gmail.com
Cc: "Marcus Boerger" helly@php.net; internals@lists.php.net; "Andi
Gutmans" andi@zend.com; "Dmitry Stogov" dmitry@zend.com
Sent: Thursday, May 17, 2007 9:54 PM
Subject: Re: [PHP-DEV] PHP 6 Preview
Oh no, you're not my problem anymore.
-Andrei
Go take a pill.
-Andrei
P.S. Open Source volunteering still implies a level of commitment.
As well as respect, something you don't have. But this stupid answer
just made my point. Fine, your problem.
Please, guys, take this argument off list if you want to continue it at all.
Yeah.
The main point Andrei tried to make was lost in that argument. PHP 6 needs
commitment from everybody involved, somewhere along the line, and we all -
even hangers-on like me - need to know that someone will step up to make
filtering possible if we're to believe in PHP 6 ever happening.Johannes and Tony both made good points. There are still issues with
streams, but more - there are real problems in the way that PHP_5_2 is seen
by many devs as the current development branch.There needs to be a sitting-back, at some point, and a 'where are we up to?'
moment. Lukas has done his utmost to provide that already, but it hasn't
changed anything that way. I'm still watching commits to PHP_5_2 that are
never merged to HEAD, and not only in ext/pdo.
I hope you write them down, so that we can beat up the guilty person^H^H^H^H^H^H^H^H^H^H keep track of them.
You still need to beat the Perl 6 release folks ;) but maybe pushing too
hard isn't the way to go about it... I don't know. I just know the
commitment hasn't been made yet for it to happen.
--
Wbr,
Antony Dovgal
2007/5/17, Steph Fox steph@zend.com:
You still need to beat the Perl 6 release folks ;)
What PHP6 needs is not repeating the same old mistakes over and
over again :
-
It should be developed without pressure, with quality being more
important than schedule, or you expect the first PHP6 releases to be
as buggy and broken as 5.0.x series do you ? -
It should have the less possible BC breaks, otherwise it will end
up in a much worse scenario than PHP5 is nowdays ( aka. a very small
adoption after 4 years), yes , Unicode is a nice feature, but not
everyone cares about that. ( I guess Europe and Asia does though) -
pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.
- pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.
One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.
This is different from the case where only that one person is actually
capable of doing the work; pressuring them then is not so good.
--Wez.
- pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.
Yes, and I did so, I gave the hand to Sara and Andrei. Until I got the
thing back on my todo lists without explanations.
This is different from the case where only that one person is actually
capable of doing the work; pressuring them then is not so good.
Nothing justifies what he said and how he said it. It is not good to
act like that, no matter why or who. Remember your blog's post about
you doing shit? It is just about the same, bad attitude and
respectless.
Can we now move to something more constructive?
--Pierre
Hello Wez.
- pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.
I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?
If no, please say so, we'll start looking for new maintainers.
This is different from the case where only that one person is actually
capable of doing the work; pressuring them then is not so good.
--
Wbr,
Antony Dovgal
Hi Tony,
Hello Wez.
- pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?If no, please say so, we'll start looking for new maintainers.
There is four maintainers for PDO, two ro three for stream, and a new
maintainer has recently been added to COM. How hard it is to
communicate with each other without ending in such pointless
discussions?
You may ask the other maintainers to check the opened bugs and see if
they can take care of them, a short mail to Wez to know if there is
already something done or not, or to get more details. end of
communication, lesson #1 :)
--Pierre
Hi Tony,
Hello Wez.
- pressure oever developers does not make any good, is disrespectul,
specially when they are not getting paid to work.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?If no, please say so, we'll start looking for new maintainers.
There is four maintainers for PDO, two ro three for stream, and a new
maintainer has recently been added to COM. How hard it is to
communicate with each other without ending in such pointless
discussions?
Uhm..
Sorry if I wasn't clear enough, but I was talking to Wez.
From what I can see, there are no maintainers for PDO (occasional fixes mostly from Ilia,
but nobody actually looks for it), and similar situation in COM - Frank and Andy do something from
time to time, but Wez is still the initial author of the extension, so I still keep hoping he'll look
into the reports assigned to him.
--
Wbr,
Antony Dovgal
I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?If no, please say so, we'll start looking for new maintainers.
With respect Tony, I think you're being somewhat dickish here.
I'd be totally fine with you saying that if I had actually assigned
those bugs to myself, but I didn't.
It's pretty clear that I've been too busy to work on those bugs, but
that's fine; we have other people (also maintainers) that are
perfectly capable of working on them too.
It's this kind of sniping that PHP can really do without.
--Wez.
I can see 47 open bug reports assigned to you (this is
bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still
maintain these extensions?If no, please say so, we'll start looking for new maintainers.
With respect Tony, I think you're being somewhat dickish here.
I'd be totally fine with you saying that if I had actually assigned
those bugs to myself, but I didn't.It's pretty clear that I've been too busy to work on those bugs, but
that's fine; we have other people (also maintainers) that are
perfectly capable of working on them too.It's this kind of sniping that PHP can really do without.
Wez,
Tony does a difficult job of sifting through hundreds and hundreds of
bug reports every week. He fixes a lot of stuff himself and assigns
the ones he cannot to the extension maintainers. That's how it works.
I understand that it is a very demanding and at times very
frustrating work since there are tons and tons of bogus reports and
some really nasty people reporting them.
I for one appreciate that people don't have time for PHP and that is
fair enough. But I also have a great admiration for people who devote
their time for keeping an eye and resolving all those bug reports.
Edin
Dear developer team,
It's a pity that you deal so with problems..
Your team has done so many wonderful things, but only because you
have worked as team together and not against each other. Don't
forget them!
You don't aid the PHP Project if you only look for yourself and not to
your friends.
Excuse me for the off topic.
--
Best regards / Mit freundlichen Grüssen
Gianni Annunzio
I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?If no, please say so, we'll start looking for new maintainers.
With respect Tony, I think you're being somewhat dickish here.
I'd be totally fine with you saying that if I had actually assigned
those bugs to myself, but I didn't.
Most of the reports are assigned by other people, that's how it works.
It's pretty clear that I've been too busy to work on those bugs, but
that's fine; we have other people (also maintainers) that are
perfectly capable of working on them too.It's this kind of sniping that PHP can really do without.
Don't get me wrong, Wez.
You know that we got along very good for a long time and I'd still like to continue working with you.
But the current situation with PDO is really annoying - the extension which was
supposed to be one of the main PHP5 features (and the idea was brilliant, that's true)
is in terrible state - no support, tens of open bugs (still open for months) and you don't seem to care.
Same for COM and openssl (thanks to Pierre, it's changed recently).
Yeah, I know very well that you're busy. So are all of us. And that's understandable.
But if you are busy and not going to maintain PDO, let's do the right thing - step up and say:
"I won't do it anymore, does anybody want to take it over?"
It's not about you personally, the very same situation we have with several other extensions:
ext/session, ext/wddx, ext/ftp, their authors are either gone or just don't care.
Who supports ext/xmlrpc nowadays? Those weird SAPIs for toy web-servers? Nobody.
They are still "maintained", but the quotes change the meaning to "forgotten".
I just want to clarify this situation - either the maintainers are temporarily busy and will
continue working on their extensions or they have to admit that they won't do it anymore,
we'll mark the extensions as orphaned and start looking for other maintainers.
One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You said it yourself.
--
Wbr,
Antony Dovgal
My point is, you can't assign stuff to someone that you know is busy,
without asking them, and then expect to be justified when you complain
that they haven't done anything.
Andrei's point was, you can't keep telling someone that you're doing
something, and then get uppity when everyone is waiting on you to get
it done after no visible progress.
There is a distinction.
With regards to the bugs assigned to me, as I just said, there are
other maintainers that can work on them, and I don't appreciate being
singled out here, again (I remember the last retarded thread about
dropping COM support...), when it is known that a) I am busy, and b)
there are other people that have volunteered to work on these areas.
If you guys need my help on a specific problem, drop me a line and I
can try to squeeze in some time to look at it. Assigning bugs to me
and getting angry about it is your problem, not mine.
--Wez.
I can see 47 open bug reports assigned to you (this is bugs.php.net only, there are also 25+ bug reports in PECL).
Most of the reports are COM, PDO or streams related. Do you still maintain these extensions?If no, please say so, we'll start looking for new maintainers.
With respect Tony, I think you're being somewhat dickish here.
I'd be totally fine with you saying that if I had actually assigned
those bugs to myself, but I didn't.Most of the reports are assigned by other people, that's how it works.
It's pretty clear that I've been too busy to work on those bugs, but
that's fine; we have other people (also maintainers) that are
perfectly capable of working on them too.It's this kind of sniping that PHP can really do without.
Don't get me wrong, Wez.
You know that we got along very good for a long time and I'd still like to continue working with you.But the current situation with PDO is really annoying - the extension which was
supposed to be one of the main PHP5 features (and the idea was brilliant, that's true)
is in terrible state - no support, tens of open bugs (still open for months) and you don't seem to care.
Same for COM and openssl (thanks to Pierre, it's changed recently).Yeah, I know very well that you're busy. So are all of us. And that's understandable.
But if you are busy and not going to maintain PDO, let's do the right thing - step up and say:
"I won't do it anymore, does anybody want to take it over?"It's not about you personally, the very same situation we have with several other extensions:
ext/session, ext/wddx, ext/ftp, their authors are either gone or just don't care.
Who supports ext/xmlrpc nowadays? Those weird SAPIs for toy web-servers? Nobody.
They are still "maintained", but the quotes change the meaning to "forgotten".I just want to clarify this situation - either the maintainers are temporarily busy and will
continue working on their extensions or they have to admit that they won't do it anymore,
we'll mark the extensions as orphaned and start looking for other maintainers.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You said it yourself.--
Wbr,
Antony Dovgal
My point is, you can't assign stuff to someone that you know is busy,
without asking them, and then expect to be justified when you complain
that they haven't done anything.Andrei's point was, you can't keep telling someone that you're doing
something, and then get uppity when everyone is waiting on you to get
it done after no visible progress.There is a distinction.
With regards to the bugs assigned to me, as I just said, there are
other maintainers that can work on them, and I don't appreciate being
singled out here, again (I remember the last retarded thread about
dropping COM support...), when it is known that a) I am busy, and b)
there are other people that have volunteered to work on these areas.
Wez, assigned bugs are just a part of the problem.
Looks like you stopped reading my mail somewhere in the middle and the second part is lost.
Ok, I'll try to clarify it again.
You did a great (I mean GREAT) job for PHP in the past and you seem to be 101% busy with your
(real) job during the last months. That's completely understandable, but we should know what to
do with the code you wrote - either you're still going to work on it or we can forget about
it and move along.
That's what I'm trying to understand - do you still maintain these things or should I stop bothering very busy person?
I'm not getting angry, I'm just asking a question.
Today we have "maintained" extensions and maintained (without quotes) extensions,
we need to separate them somehow just to be honest with the users and with ourselves.
This way we also could speed up the process a bit, as the bugs wouldn't be assigned to wrong persons.
The same question applies to other maintainers of "maintained" extensions, but you just happened
to say the thing which reminded me that I wanted to start this discussion looong ago..
If you guys need my help on a specific problem, drop me a line and I
can try to squeeze in some time to look at it. Assigning bugs to me
and getting angry about it is your problem, not mine.
No, there is no some specific problem, there is a major problem with the quotes around the word "maintained".
We either need to remove them or be honest and change it to unmaintained.
--
Wbr,
Antony Dovgal
Hi Wez,
My point is, you can't assign stuff to someone that you know is busy,
without asking them, and then expect to be justified when you complain
that they haven't done anything.Andrei's point was, you can't keep telling someone that you're doing
something, and then get uppity when everyone is waiting on you to get
it done after no visible progress.There is a distinction.
There is indeed a distinction. But I suggest you stop to spread wrong
informations and give excuses to an unacceptable behavior. Again, I
gave the hand months ago and I still have no idea why it was sent back
to me ~2 months ago.
I'm out of this thread now.
I wonder why you even joined it. It is getting pathetic to see such
things in this list.It is ridiculous and a shame for PHP.
--Pierre
I just want to clarify this situation - either the maintainers are temporarily busy and will
continue working on their extensions or they have to admit that they won't do it anymore,
we'll mark the extensions as orphaned and start looking for other maintainers.
I'm going to say it one last time: there are other maintainers.
I'm temporarily too busy, but we have other maintainers.
Please assign bugs to the other maintainers.
I will try to look at my assigned bugs as I have time and goodwill.
Each thread like this reduces my goodwill for PHP dev, because it
turns from a fun thing to do on the weekend to a petty political mess
that no one wants to be involved in.
One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You said it yourself.
Yes. And perhaps because English is a crazy language, I want to point
out, again, that I didn't accept each individual bug, only to never
work on it.
I'm out of this thread now.
--Wez.
Wez Furlong wrote:
I'm going to say it one last time: there are other maintainers.
I'm temporarily too busy, but we have other maintainers.
Please assign bugs to the other maintainers.
Maybe per-extension aliases (such as extension-name@bugs.php.net) could
help here? This way it would be possible to assign a bug not to a single
person but to a group.
Sebastian Bergmann wrote:
Wez Furlong wrote:
I'm going to say it one last time: there are other maintainers.
I'm temporarily too busy, but we have other maintainers.
Please assign bugs to the other maintainers.Maybe per-extension aliases (such as extension-name@bugs.php.net) could
help here? This way it would be possible to assign a bug not to a single
person but to a group.
This thread has nothing to do with me, (except with regards to my
interest in PHP6) but in my experience when a task is assigned to a
group not an individual there is no accountability and no incentive to
either get it done or pass it to someone who can. IMHO it's better to
leave it unassigned than to assign it to a group.
Surely it should be the responsibility of the maintainers to keep an eye
on incoming bugs, and the person monitoring new bugs should simply be
making sure they have been reported correctly and against the right
category/project. At least then you can get an accurate picture from the
bug list.
-Stut
Stut wrote:
This thread has nothing to do with me, (except with regards to my
interest in PHP6) but in my experience when a task is assigned to a
group not an individual there is no accountability and no incentive to
either get it done or pass it to someone who can. IMHO it's better to
leave it unassigned than to assign it to a group.
The system I described worked fine for the team I worked with during
my time as a Gentoo developer. YMMV, of course.
I just want to clarify this situation - either the maintainers are
temporarily busy and will continue working on their extensions or they
have to admit that they won't do it anymore, we'll mark the extensions as
orphaned and start looking for other maintainers.I'm going to say it one last time: there are other maintainers.
I'm temporarily too busy, but we have other maintainers.
Please assign bugs to the other maintainers.
Jee guys, why don't we just have a status for each maintainer. That way if a
maintainer is busy with their personal life/work, their name will not show in
the assign to list and an other maintainer will get picked to be assigned
with the bug report. Wouldn't this avoid all this pointless discussion?
my 2c
I will try to look at my assigned bugs as I have time and goodwill.
Each thread like this reduces my goodwill for PHP dev, because it
turns from a fun thing to do on the weekend to a petty political mess
that no one wants to be involved in.One of the points that Andrei was trying to make was that if you
really don't have time for something, you should say so, so that other
people that do have the time can step forward and help out.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You said it yourself.Yes. And perhaps because English is a crazy language, I want to point
out, again, that I didn't accept each individual bug, only to never
work on it.I'm out of this thread now.
--Wez.
--
Powered by openSUSE 10.2 (i586) Kernel: 2.6.18.8-0.3-default
KDE: 3.5.5 "release 45.4"
10:51am up 7 days 23:21, 9 users, load average: 0.14, 0.30, 0.62
Jeffery Fernandez wrote:
I just want to clarify this situation - either the maintainers are
temporarily busy and will continue working on their extensions or they
have to admit that they won't do it anymore, we'll mark the extensions as
orphaned and start looking for other maintainers.
I'm going to say it one last time: there are other maintainers.
I'm temporarily too busy, but we have other maintainers.
Please assign bugs to the other maintainers.Jee guys, why don't we just have a status for each maintainer. That way if a
maintainer is busy with their personal life/work, their name will not show in
the assign to list and an other maintainer will get picked to be assigned
with the bug report. Wouldn't this avoid all this pointless discussion?
I don't see ANY reason bugs should be assigned by anybody other than the
person who is ACTUALLY working on it?
IF someone has time or has found a fix for a problem, THEY assign the bug to
them selves and put up the fix.
Someone else 'deciding' that so and so is going to fix such and such is simply
not practical unless that person is also PAYING to have work done - which is
not the case on PHP.
Requests for someone to LOOK at a particular bug could be made, but the
decision on assignment should only be made by the person DOING the work?
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
I don't see ANY reason bugs should be assigned by anybody other than the
person who is ACTUALLY working on it?
IF someone has time or has found a fix for a problem, THEY assign the
bug to them selves and put up the fix.
Well, there's a reason - not every developer watches bugs closely.
Thanks to great work by Antony, there's somebody who does that, but we
can't realistically expect every maintainer to do that, so assigning
bugs is the means to alert the developer that this bug is (at least
potentially) in his domain.
Requests for someone to LOOK at a particular bug could be made, but the
decision on assignment should only be made by the person DOING the work?
I think assignment is request to look - and if possible fix, if not -
one should indicate he can't accept it. Of course, as we know, in theory
practice follows theory, in practice it doesn't - so there are cases
where bugs are assigned but not really looked at.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Stanislav Malyshev wrote:
I don't see ANY reason bugs should be assigned by anybody other than
the person who is ACTUALLY working on it?
IF someone has time or has found a fix for a problem, THEY assign
the bug to them selves and put up the fix.Well, there's a reason - not every developer watches bugs closely.
Thanks to great work by Antony, there's somebody who does that, but we
can't realistically expect every maintainer to do that, so assigning
bugs is the means to alert the developer that this bug is (at least
potentially) in his domain.
Assigning blindly is not the right procedure. There needs to be a proper
REFERRAL process so that other people who are working in the area are made
aware of the problem. If the bug is flagged with the correct area or package
name, then anybody can pick up the baton. Simply 'assigning' a bug to say Wez
when AS HE SAYS - there are other developers - is a pointless waste of time.
Requests for someone to LOOK at a particular bug could be made, but
the decision on assignment should only be made by the person DOING the
work?I think assignment is request to look - and if possible fix, if not -
one should indicate he can't accept it. Of course, as we know, in theory
practice follows theory, in practice it doesn't - so there are cases
where bugs are assigned but not really looked at.
HOW do you 'request' a group of developers look at a bug?
Personally I scan the bug summary each week to see what has popped up on my
areas of interest ( The 'feature requests' should be killed from that !!! )
and that would seem to be the most productive method possible. Antony and
others just needs to make sure that bugs are correctly classified and
duplicates flagged and removed. There are assigned bugs there that have not
moved in months and it would be nice to see the total number of BUGS going down.
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Well, there's a reason - not every developer watches bugs closely.
Thanks to great work by Antony, there's somebody who does that, but we
can't realistically expect every maintainer to do that, so assigning
bugs is the means to alert the developer that this bug is (at least
potentially) in his domain.Assigning blindly is not the right procedure. There needs to be a proper
REFERRAL process so that other people who are working in the area are made
aware of the problem. If the bug is flagged with the correct area or package
name, then anybody can pick up the baton. Simply 'assigning' a bug to say Wez
when AS HE SAYS - there are other developers - is a pointless waste of time.
Blindly?
I'm afraid you don't understand what you're talking about.
There is EXTENSIONS file (in the sources root dir) which lists extensions along with their maintainers.
Do you see any maintainers for PDO? No? Me neither.
Then there are any maintainers for com_dotnet except Wez? Nope..
Or maybe you know any streams maintainers except Wez and Sara? Tell me.
If the file is wrong and there are other maintainers for these extensions,
then I've been totally blind for years, since I follow the CVS list pretty close
and I can distinguish between a person committing occasional fixes and maintainers
looking for the extension on a permanent basis.
I think assignment is request to look - and if possible fix, if not -
one should indicate he can't accept it. Of course, as we know, in theory
practice follows theory, in practice it doesn't - so there are cases
where bugs are assigned but not really looked at.HOW do you 'request' a group of developers look at a bug?
Personally I scan the bug summary each week to see what has popped up on my
areas of interest ( The 'feature requests' should be killed from that !!! )
and that would seem to be the most productive method possible. Antony and
others just needs to make sure that bugs are correctly classified and
duplicates flagged and removed. There are assigned bugs there that have not
moved in months and it would be nice to see the total number of BUGS going down.
Want to help me with that (or maintainers with bugs in their extensions)?
I'd gladly accept both, even though bugfixes are much more welcome =)
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Want to help me with that (or maintainers with bugs in their extensions)?
I'd gladly accept both, even though bugfixes are much more welcome =)
I'm trying to get up to speed to do work on the interbase/firebird package,
The half dozen bugs there have been around for long enough, and three of them
are 'assigned' two for a long time.
I suppose sometime someone will have to look at a Firebird/Interbase driver
for PDO although having to load the main driver anyway to get the other tools
just defeats the object. So the three suspended bugs on that are probably
correct - since no one can find a need to work on it :(
I'm still fighting to sort out the niggles that PHP5.2 introduced in
production so I can move all my sites from PHP5.1.6 but until someone NAILS
THAT DOWN :(
Lets stop making changes and move on to PHP6 PLEASE
Add shitting 'Vista' to the equation and customers expecting THAT to actually
work .....
'PHP 5 Bug Summary Report' is an tidy means of flagging all the bugs. Strip
the 'Feature Requests' and it would be a lot easier to use.
wez has some 40 bugs assigned, but has indicated that he does not have time to
deal with them, and I don't see any need to do any more than post this report
out. That should be the trigger for people who DO have time to pick problems
up and flag that they are dealing with them. Sending the same 'reminders' out
week after week .....
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
Antony Dovgal wrote:
Want to help me with that (or maintainers with bugs in their extensions)?
I'd gladly accept both, even though bugfixes are much more welcome =)I'm trying to get up to speed to do work on the interbase/firebird package,
The half dozen bugs there have been around for long enough, and three of them
are 'assigned' two for a long time.
Great news.
AFAIK Ard doesn't do PHP/Firebird anymore, so any help from you in this area would be of great value.
Especially taking into account that I don't know of any other developers using Firebird/Interbase.
Feel free to send your the questions you have (I'm sure you would have some) to the list,
I'll try to help you if I can.
I suppose sometime someone will have to look at a Firebird/Interbase driver
for PDO although having to load the main driver anyway to get the other tools
just defeats the object. So the three suspended bugs on that are probably
correct - since no one can find a need to work on it :(I'm still fighting to sort out the niggles that PHP5.2 introduced in
production so I can move all my sites from PHP5.1.6 but until someone NAILS
THAT DOWN :(
Any hints?
Lets stop making changes and move on to PHP6 PLEASE
That's my motto since the very PHP6 branch off.
Now we only need to convince the others =)
Add shitting 'Vista' to the equation and customers expecting THAT to actually
work .....'PHP 5 Bug Summary Report' is an tidy means of flagging all the bugs. Strip
the 'Feature Requests' and it would be a lot easier to use.
wez has some 40 bugs assigned, but has indicated that he does not have time to
deal with them, and I don't see any need to do any more than post this report
out. That should be the trigger for people who DO have time to pick problems
up and flag that they are dealing with them. Sending the same 'reminders' out
week after week .....
Well, "should".. yes, I guess it should.
But does it?
--
Wbr,
Antony Dovgal
Add shitting 'Vista' to the equation and customers expecting THAT to actually
work .....
I'm not sure if you meant shipping or adding Vista to a shit list. :)
--Wez.
(this is not the thread I was looking for <jedi-hand-wave/>)
Wez Furlong wrote:
Add shitting 'Vista' to the equation and customers expecting THAT to
actually
work .....I'm not sure if you meant shipping or adding Vista to a shit list. :)
Replace 'shitting' with other less polite terms ;)
The only reason vista exists is to tighten M$'s hold on DRM - something that
has no place in ANY modern office environment, so we DO need a real operating
system that does not provide all the multimedia crap when all the machine
needs to do is work like a good old fashioned typewriter. Having to go out to
sites to fix things that are only broken because of the multimedia crap is
getting pigging annoying :(
--
Lester Caine - G8HFL
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
There is EXTENSIONS file (in the sources root dir) which lists extensions along with their maintainers.
PECL has its own way to indicate the maintainers too (checkout the
package.xml files), so that extensions file, which has almost never
been up to date, isn't the definitive source of information.
--Wez.
(who's not really in this thread anymore. This post is a figment of
your imagination)
Hi Wez,
There is EXTENSIONS file (in the sources root dir) which lists extensions along with their maintainers.
PECL has its own way to indicate the maintainers too (checkout the
package.xml files), so that extensions file, which has almost never
been up to date, isn't the definitive source of information.
I can imagine something similar using the EXTENSION/CREDITS files. As
long as we have valid emails, it should work well. No need to assign
to one of the maintainers as they will all get the emails. Will it
help us to work more or faster? No idea ;-)
--Wez.
(who's not really in this thread anymore. This post is a figment of
your imagination)