A good deal of time has passed and it seems Derick and Pierre are no
closer to the consensus about the filter extension and in the
meantime 5.2 release process is stalling. At this point I think as
the Release Manager I need make a decision on how to proceed. Before
I make a decision I'd like to hear some feedback from other
developers and users of PHP on what they think.
The current options are:
[ ] Indefinitely delay 5.2 release until filter issue can be resolved.
[ ] Remove filter from PHP 5.2 and hope that some near-future release
will re-introduce it
[ ] Go with what we have right now, and if filter developers want to
make changes they'll need to do so in a manner backwards compatible
to the current code.
Personally, I'd prefer to take filter out entirely from the 5.2 tree.
Ilia Alshanetsky
A good deal of time has passed and it seems Derick and Pierre
are no closer to the consensus about the filter extension and
in the meantime 5.2 release process is stalling. At this
point I think as the Release Manager I need make a decision
on how to proceed. Before I make a decision I'd like to hear
some feedback from other developers and users of PHP on what
they think.The current options are:
[ ] Indefinitely delay 5.2 release until filter issue can be resolved.
[ ] Remove filter from PHP 5.2 and hope that some near-future
release will re-introduce it [ ] Go with what we have right
now, and if filter developers want to make changes they'll
need to do so in a manner backwards compatible to the current code.Personally, I'd prefer to take filter out entirely from the 5.2 tree.
If the filter extension goes in now and remains marked 'experimental',
making changes that break BC is moot - that's why it's marked experimental
and the docs explain that very clearly - things can and probably will
change.
IMHO, it should go in as is and the 5.2 cycle resumed and completed. If
the guys needed another few days to arrive at a concensus I would consider
that a fair price to pay in order to mitigate BC breaks in the future,
but that additional delay would be at your discretion of course.
Best Regards
Mike Robinson
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.407 / Virus Database: 268.12.9/458 - Release Date: 9/27/2006
A good deal of time has passed and it seems Derick and Pierre are no closer to
the consensus about the filter extension and in the meantime 5.2 release
process is stalling. At this point I think as the Release Manager I need make
a decision on how to proceed. Before I make a decision I'd like to hear some
feedback from other developers and users of PHP on what they think.
Instead of calling for a vote on this I'd rather see you giving comments
to the thread that discusses this issue.
regards,
Derick
Hello,
A good deal of time has passed and it seems Derick and Pierre are no closer to
the consensus about the filter extension and in the meantime 5.2 release
process is stalling. At this point I think as the Release Manager I need make
a decision on how to proceed. Before I make a decision I'd like to hear some
feedback from other developers and users of PHP on what they think.Instead of calling for a vote on this I'd rather see you giving comments
to the thread that discusses this issue.
Ilia gave comments, feedbacks, fixes and agreed on the proposal as all
other. We all agreed on an API. Only you do not agree and keep try to
change things. It is not badly meant, only a fact :)
I will not repeat that again but it is time now to give up, and move
on the next steps.
--Pierre
Ilia Alshanetsky wrote:
I make a
decision I'd like to hear some feedback from other developers and users
of PHP on what they think.
Personally, I'd prefer to take filter out entirely from the 5.2 tree.
I would like to see it stay, this extension is the one that will finally
shut the "PHP IS INSECURE" crowd up.
The extension makes sense. The ease of coding PHP has been its greatest
asset and also its greatest flaw. Newbie coders can quickly make
something work and have a PHP/MySQL powered site with little knowledge.
Of course, when it comes to securing these sites these same people are
clueless. When I answer queries on #php (kill me) myself and others are
constantly fighting a battle to tell folks how to do simple things like
validating data from users, use prepared statements etc.
The filter extension will bring a simple interface to these users who
will be able to build more secure applications/sites without having to
write validation classes etc.
What form the extension finally takes is important for the future, but
for most developers out there using this stuff, it is important that it
stays. We can say to prospective clients "PHP has a full array of
security based functions to be sure your applications is <insert
buzzword> ready for real world use.
my $0.02
Kevin
Ilia Alshanetsky wrote:
A good deal of time has passed and it seems Derick and Pierre are no
closer to the consensus about the filter extension and in the meantime
5.2 release process is stalling.
It would be nice if it could be decided who is in charge of this
extension. Since Rasmus and Derick did all the initial work on the
extension I think it should be them, and not Pierre.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Hello Sebastian,
Ilia Alshanetsky wrote:
A good deal of time has passed and it seems Derick and Pierre are no
closer to the consensus about the filter extension and in the meantime
5.2 release process is stalling.It would be nice if it could be decided who is in charge of this
extension. Since Rasmus and Derick did all the initial work on the
extension I think it should be them, and not Pierre.
We are talking about something that will affect all single PHP
setup. It is not like a foobar extension. So no, it is not me, Rasmus
or Derick alone who should decide.
Also please consider to see the facts, I did not decide, I proposed
and asked numerous times, you decided.
--Pierre
Sebastian Bergmann wrote:
It would be nice if it could be decided who is in charge of this
extension. Since Rasmus and Derick did all the initial work on the
extension I think it should be them, and not Pierre.
I agree that we need someone in charge. But I also think that the
initial work only gives ownership for a short while, after that it
should be controlled by whoever is active.
The last patch I saw was from Pierre, maybe Derick should also prepare
one and we should have a patch shoot-out :-)
While this sounds like a joke it could break the stalling going on. And
while I think both Derick and Pierre can come up with a decent interface
I would be very sad if none of it would make it into 5.2 as I agree that
it's an important set of functions.
So my vote is for
[X] Indefinitely delay 5.2 release until filter issue can be resolved.
with the addition that we should find a way (e.g. shoot-out) to make
"Indefinitely" not longer than 1 or 2 weeks.
- Chris
Hi Chirstian,
Sebastian Bergmann wrote:
It would be nice if it could be decided who is in charge of this
extension. Since Rasmus and Derick did all the initial work on the
extension I think it should be them, and not Pierre.I agree that we need someone in charge. But I also think that the
initial work only gives ownership for a short while, after that it
should be controlled by whoever is active.The last patch I saw was from Pierre, maybe Derick should also prepare
one and we should have a patch shoot-out :-)While this sounds like a joke it could break the stalling going on.
This patch is more than only changing the API to fit to our decisions.
The (bad) joke is to be here talking again about something we agreed
on two weeks ago.
--Pierre
Pierre wrote:
This patch is more than only changing the API to fit to our decisions.
I know. That's why Derick's patch would have to be on par to be competitive.
The (bad) joke is to be here talking again about something we agreed
on two weeks ago.
While I agree with you the problem is that it's as of now unclear who's
in the driver seat of the filter extension: You or Derick.
We need someone or some process (like the semi-seriously proposed
shoot-out) to decide who's in charge.
Reminds me of the posting by the NetBSD guy Hannum (especially the part
about locking of projects and meritocracy):
http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
- Chris
Hello,
Pierre wrote:
This patch is more than only changing the API to fit to our decisions.
I know. That's why Derick's patch would have to be on par to be competitive.
There is no competition, fight or any other stupid things like that.
We have a release to finish, with the best possible compromises for
all new APIs or extensions.
The (bad) joke is to be here talking again about something we agreed
on two weeks ago.While I agree with you the problem is that it's as of now unclear who's
in the driver seat of the filter extension: You or Derick.We need someone or some process (like the semi-seriously proposed
shoot-out) to decide who's in charge.
No, we need a way to tell Derick to accept our choices and the
compromises we made. Just like I accepted to rename my Zip class even
if I strongly disagreed. This is how it works, period.
--Pierre
Pierre wrote:
There is no competition, fight or any other stupid things like that.
Competition is not stupid and if two people provide a solution the
better should get accepted. If we only have one solution at hand then
it's certainly obvious which one should be chosen.
No, we need a way to tell Derick to accept our choices and the
That would assume we have a strong leadership in the PHP project.
Doesn't seem to be the case (at least not in this case).
Could someone respected by everybody please step up? Andi? (-;C
Anyway, I think my point got across, have a nice weekend,
- Chris
On Fri, 29 Sep 2006 14:38:12 +0200
cschneid@cschneid.com (Christian Schneider) wrote:
Pierre wrote:
There is no competition, fight or any other stupid things like that.
Competition is not stupid and if two people provide a solution the
better should get accepted. If we only have one solution at hand then
it's certainly obvious which one should be chosen.
Competition is stupid when player(s) come in once the game is over.
After four RCs, two proposals and finally a large agreement, the game is
over.
-- Pierre
On Fri, 29 Sep 2006 14:14:54 +0200
cschneid@cschneid.com (Christian Schneider) wrote:
While I agree with you the problem is that it's as of now unclear
who's in the driver seat of the filter extension: You or Derick.
Forgot to answer to this specific part.
Let me say it again: The leads of this extension are all active PHP
Internals developers. The reason is simple, this extension affects PHP
on each single request, it will be installed and available everywhere.
Its code will be executed, whether you use filter or not.
If I did not harass the list with my calls for reviews, feedbacks,
tests or API proposals, we will still have a non working extension. An
extension you can compile barely only on Derick's box and
having segfaults than valid values.
I'm not saying that the extension was badly implemented or designed,
only that it was not ready to be bundled, even not ready to be
tagged as beta. I brought it to the required stability (both from API
and implementation) to be included in php, with the requested features
or options.
All my choices have been based on users request and public discussions
and polls.
The rest is pure politics and marketing crap. I refused to play this
game to get things done in time because I am (and was) ready in time.
Ok, I said all I have to say about this topic now :)
-- Pierre
A good deal of time has passed and it seems Derick and Pierre are no
closer to the consensus about the filter extension and in the
meantime 5.2 release process is stalling. At this point I think as
the Release Manager I need make a decision on how to proceed. Before
I make a decision I'd like to hear some feedback from other
developers and users of PHP on what they think.The current options are:
[ ] Indefinitely delay 5.2 release until filter issue can be resolved.
[ ] Remove filter from PHP 5.2 and hope that some near-future release
will re-introduce it
[ ] Go with what we have right now, and if filter developers want to
make changes they'll need to do so in a manner backwards compatible
to the current code.
+1 for Go with what we have. As said, it IS experimental. But it is an
important extension to assist in securing PHP input's.
(P.S. Am I allowed to vote? I'm over 21! I'm not black and I'm employed.)
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
A good deal of time has passed and it seems Derick and Pierre are no
closer to the consensus about the filter extension and in the
meantime 5.2 release process is stalling. At this point I think as
the Release Manager I need make a decision on how to proceed. Before
I make a decision I'd like to hear some feedback from other
developers and users of PHP on what they think.The current options are:
I would like to see one more RC released.
And I think a total freeze after this RC would make a lot of sense, since we keep changing the code in every RC..
[x] Indefinitely delay 5.2 release until filter issue can be resolved.
[ ] Remove filter from PHP 5.2 and hope that some near-future release
will re-introduce it
[ ] Go with what we have right now, and if filter developers want to
make changes they'll need to do so in a manner backwards compatible
to the current code.
--
Wbr,
Antony Dovgal
A good deal of time has passed and it seems Derick and Pierre are
no closer to the consensus about the filter extension and in the
meantime 5.2 release process is stalling. At this point I think
as the Release Manager I need make a decision on how to proceed.
Before I make a decision I'd like to hear some feedback from
other developers and users of PHP on what they think.
The current options are:I would like to see one more RC released.
And I think a total freeze after this RC would make a lot of
sense, since we keep changing the code in every RC..
There will definitely be an RC5, quantity of changes made since RC4
warrants it, but after this RC I'd like to "close the tree" so we
need to resolve the filter issue now.
Ilia Alshanetsky
A good deal of time has passed and it seems Derick and Pierre are
no closer to the consensus about the filter extension and in the
meantime 5.2 release process is stalling. At this point I think
as the Release Manager I need make a decision on how to proceed.
Before I make a decision I'd like to hear some feedback from
other developers and users of PHP on what they think.
The current options are:I would like to see one more RC released.
And I think a total freeze after this RC would make a lot of
sense, since we keep changing the code in every RC..There will definitely be an RC5, quantity of changes made since RC4
warrants it, but after this RC I'd like to "close the tree" so we
need to resolve the filter issue now.
Perfect.
In this case I'd give my vote for:
[x] Go with what we have right now, and if filter developers want to
make changes they'll need to do so in a manner backwards compatible
to the current code.
--
Wbr,
Antony Dovgal