Hi!
We're having pretty lively discussion on the list, twitter and other
places, but let's not forget the big goal of 5.4 :)
- First of all, the official business. Any objections to the RMs for
5.4 being:
Stas Malyshev (stas)
David Soria Parra (dsp)
If not, we'll be the 5.4 RM team.
- Candidates for 5.4: please review this list:
https://wiki.php.net/todo/php54
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access to
wiki machine and I'll install it :)
Some of the items are already being discussed, but I'll prepare some
kind of official "ballot" and send to the list soon so we'd have common
point.
I think it makes sense to have the following limits of the features:
a. It should be either obvious how to do it (example: adding E_STRICT to
E_ALL), or have full design & working patch w/tests or somebody has to
commit to doing it within roughly a month term.
b. I think we should leave out any big things now, e.g.: annotations -
sorry, I know there are many people supporting it, but right now it
doesn't seem to be a consensus on how to do it, so I'd rather target 5.5
for it, which if we can make this release go smoothly won't have to be
too far out.
- I'd like to create first alpha sometime next week, if somebody has
anything that's not in and wants it in please talk to me. This alpha
should in no way be seen as anything stable or final, but rather as a
first step on a road to 5.4.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
I have no objection as long as the RFC for the release process is
adopted before we do any 5.4 releases, as stated earlier, this is the
only way to put ourself on the safe side.
Cheers,
Hi!
We're having pretty lively discussion on the list, twitter and other places,
but let's not forget the big goal of 5.4 :)
- First of all, the official business. Any objections to the RMs for 5.4
being:
Stas Malyshev (stas)
David Soria Parra (dsp)If not, we'll be the 5.4 RM team.
- Candidates for 5.4: please review this list:
https://wiki.php.net/todo/php54I'd like to set up a vote for the undecided TODO features on wiki.php.net,
anybody could help me with setting up the voting module there if there's
such thing on the wiki? Or set me up with the access to wiki machine and
I'll install it :)Some of the items are already being discussed, but I'll prepare some kind of
official "ballot" and send to the list soon so we'd have common point.I think it makes sense to have the following limits of the features:
a. It should be either obvious how to do it (example: addingE_STRICTto
E_ALL), or have full design & working patch w/tests or somebody has to
commit to doing it within roughly a month term.b. I think we should leave out any big things now, e.g.: annotations -
sorry, I know there are many people supporting it, but right now it doesn't
seem to be a consensus on how to do it, so I'd rather target 5.5 for it,
which if we can make this release go smoothly won't have to be too far out.
- I'd like to create first alpha sometime next week, if somebody has
anything that's not in and wants it in please talk to me. This alpha should
in no way be seen as anything stable or final, but rather as a first step on
a road to 5.4.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Sounds fine to me.
Hi!
We're having pretty lively discussion on the list, twitter and other places,
but let's not forget the big goal of 5.4 :)
- First of all, the official business. Any objections to the RMs for 5.4
being:
Stas Malyshev (stas)
David Soria Parra (dsp)If not, we'll be the 5.4 RM team.
- Candidates for 5.4: please review this list:
https://wiki.php.net/todo/php54I'd like to set up a vote for the undecided TODO features on wiki.php.net,
anybody could help me with setting up the voting module there if there's
such thing on the wiki? Or set me up with the access to wiki machine and
I'll install it :)Some of the items are already being discussed, but I'll prepare some kind of
official "ballot" and send to the list soon so we'd have common point.I think it makes sense to have the following limits of the features:
a. It should be either obvious how to do it (example: addingE_STRICTto
E_ALL), or have full design & working patch w/tests or somebody has to
commit to doing it within roughly a month term.b. I think we should leave out any big things now, e.g.: annotations -
sorry, I know there are many people supporting it, but right now it doesn't
seem to be a consensus on how to do it, so I'd rather target 5.5 for it,
which if we can make this release go smoothly won't have to be too far out.
- I'd like to create first alpha sometime next week, if somebody has
anything that's not in and wants it in please talk to me. This alpha should
in no way be seen as anything stable or final, but rather as a first step on
a road to 5.4.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I'd like to set up a vote for the undecided TODO features on wiki.php.net,
anybody could help me with setting up the voting module there if there's
such thing on the wiki? Or set me up with the access to wiki machine and
I'll install it :)
You are in general much more likely to get serious reply on this sort
of things on the.. mailinglists dedicated for it (php-webmaster@ /
systems@). There is just way to much trolling going on on this list
for us to be able to read all posts.
The wiki code is in svn, so you should be able to commit whatever
plugin you need.
If you need access to the actual box, ask the technical contact listed
on https://wiki.php.net/systems/rl, or systems@ for any other
questions.
Some of the items are already being discussed, but I'll prepare some kind of
official "ballot" and send to the list soon so we'd have common point.
There are still leftovers from the scalar type hint in svn, check
zend_do_receive_arg() and zend_do_perform_implementation_check() for
example.
Please verify you reverted it properly, as these half-reverting is
causing segfaults whereas syntax error would be expected.
-Hannes
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access
to wiki machine and I'll install it :)
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showing
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).
Derick
2011/6/3 Derick Rethans derick@php.net:
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access
to wiki machine and I'll install it :)Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showing
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).
Why not just to separate voting from participation? I doubt there is
somebody that counts all these +1 in the list and tracks progress.
I suggest keep voting only in wiki and discussions in ML. Don't have
consice opinion yet? Participate ML. Got opinion? Go and vote in the
wiki, no need to +1/-1 in the list, it's already too much noise here.
Derick
--
--
Regards,
Shein Alexey
Hi!
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showing
Voting on ML is messy and means somebody needs to read every message on
the list and look for votes, however long, tedious and offtopic the
discussion gets. Voting with, well, voting application is clean,
automatic and efficient. I don't understand why we should use medium
that is unfit for the purpose instead of using applications specifically
designed for doing what we try to do.
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).
There will be exposure to the list, with list of topics and explanations.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP! (although soon PJSON)
Hi!
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showingVoting on ML is messy and means somebody needs to read every message on the list and look for votes, however long, tedious and offtopic the discussion gets. Voting with, well, voting application is clean, automatic and efficient. I don't understand why we should use medium that is unfit for the purpose instead of using applications specifically designed for doing what we try to do.
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).There will be exposure to the list, with list of topics and explanations.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showingVoting on ML is messy and means somebody needs to read every message on the
list and look for votes, however long, tedious and offtopic the discussion
gets. Voting with, well, voting application is clean, automatic and efficient.
I don't understand why we should use medium that is unfit for the purpose
instead of using applications specifically designed for doing what we try to
do.
Yes, it's messy on ML. My points where:
- a call to vote is easily drowned out on the ML with all the noise
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).
And IMO, those two things should be sorted out before we "decide" to do
votes by editting some page on some wiki.
Derick
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showingVoting on ML is messy and means somebody needs to read every message on the
list and look for votes, however long, tedious and offtopic the discussion
gets. Voting with, well, voting application is clean, automatic and efficient.
I don't understand why we should use medium that is unfit for the purpose
instead of using applications specifically designed for doing what we try to
do.Yes, it's messy on ML. My points where:
- a call to vote is easily drowned out on the ML with all the noise
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).
There is a log and we know who did edit what. Basic trust is required
anyway and if such tricks happen, really, I do not know what to think
about the person doing them (well I do, but that's not the place to
say it).
A plugin will be installed to ease the process, login, vote. You won't
be able to add/edit other votes.
About when a vote happens and how to inform the devs, I do not see
other solutions than getting the devs to read the discussions on the
MLs. If some can't stand the heat, then we can't do much for them
anyway,
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Have you guys considered doodle.com? I think you are all stressing way too
much over the voting process. When a vote is closed you can then transfer
the decision to the RFC.
Drak
Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are
showingVoting on ML is messy and means somebody needs to read every message on
the
list and look for votes, however long, tedious and offtopic the
discussion
gets. Voting with, well, voting application is clean, automatic and
efficient.
I don't understand why we should use medium that is unfit for the
purpose
instead of using applications specifically designed for doing what we
try to
do.Yes, it's messy on ML. My points where:
- a call to vote is easily drowned out on the ML with all the noise
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).There is a log and we know who did edit what. Basic trust is required
anyway and if such tricks happen, really, I do not know what to think
about the person doing them (well I do, but that's not the place to
say it).A plugin will be installed to ease the process, login, vote. You won't
be able to add/edit other votes.About when a vote happens and how to inform the devs, I do not see
other solutions than getting the devs to read the discussions on the
MLs. If some can't stand the heat, then we can't do much for them
anyway,Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for votes. Also, voting on ML
does not solve the "drowning out" problem, it makes it worse as about
80% of the people in given vote in a given moment can't say what they
are/supposed to be voting for, is discussion still ongoing and what's
the consensus, if any.
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).
Votes are public, if you see somebody edited it you'd notice. As editing
could be done only by admins (if I understand correctly, same guys
having root on pretty much all PHP infrastructure) if a plugin is used
(see below) I don't think it's a big concern.
And IMO, those two things should be sorted out before we "decide" to do
votes by editting some page on some wiki.
docuwiki has voting plugins for that purpose, editing some page is not
the only way. For example: http://www.dokuwiki.org/plugin:doodle2
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for votes.
That is subjective. And even with a threaded client, if there are 80+
new messages then the call for vote is drowned out. Requiring
something like [VOTE] in the subject helps, as then you can set-up a
filter. And if it's a requirement, every call without [VOTE] in the
subject is invalid. (Easy to fix if somebody forgot it as well). It
would expose this kind of thing.
Also, voting on ML does not solve the "drowning out" problem, it makes
it worse as about 80% of the people in given vote in a given moment
can't say what they are/supposed to be voting for, is discussion still
ongoing and what's the consensus, if any.
I didn't disagree with this.
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).Votes are public, if you see somebody edited it you'd notice. As
editing could be done only by admins (if I understand correctly, same
guys having root on pretty much all PHP infrastructure) if a plugin is
used (see below) I don't think it's a big concern.And IMO, those two things should be sorted out before we "decide" to do
votes by editting some page on some wiki.docuwiki has voting plugins for that purpose, editing some page is not the
only way. For example: http://www.dokuwiki.org/plugin:doodle2
There is no plugin used for it yet, and that's my problem with it.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for votes.
That is subjective. And even with a threaded client, if there are 80+
new messages then the call for vote is drowned out.
We have at leasta million PHP users. Maybe a billion now. (For those
who were educated in the United States, a billion is a thousand times
a million).
If someone can't handle as mere 80 votes, well... maybe that's the problem.
Requiring
something like [VOTE] in the subject helps, as then you can set-up a
filter. And if it's a requirement, every call without [VOTE] in the
subject is invalid. (Easy to fix if somebody forgot it as well). It
would expose this kind of thing.
Read. Every. Message... or figure out another way.
If you do not have the time to do so, maybe it's time to "check out"
of a project. I read 900+ emails a day. I do not think others are
incapable of this.
Also, voting on ML does not solve the "drowning out" problem, it makes
it worse as about 80% of the people in given vote in a given moment
can't say what they are/supposed to be voting for, is discussion still
ongoing and what's the consensus, if any.
I didn't disagree with this.
All voting is messy. As are opinions.
- editting votes on a wiki can too easily be manipulated (I could just
change your votes, and there would be no trail).
Votes are public, if you see somebody edited it you'd notice. As
editing could be done only by admins (if I understand correctly, same
guys having root on pretty much all PHP infrastructure) if a plugin is
used (see below) I don't think it's a big concern.
And IMO, those two things should be sorted out before we "decide" to do
votes by editting some page on some wiki.
My problem is with the idea, and practice, of astroturfing, and other
vote stacking methods. Moving from a mailinglist to a wiki does not
change this problem, it just provides another media to play with....
without addressing the issue.
I've been with the PHP project, off and on, for at least ten years now
(hell, I have had "core commit" for ages, but rasmus, stas, zeev, andi
wouldn't even recognize my face). and I've seen... interesting....
things over the years. It's not a democracy, it's a meritocracy. Votes
don't count for much, other than expressing interest. If you want to
change core, you have to send patches.
Good patches.
Working patches.
Patches that don't fuck up testers,
We can argue for years about whether or not code should be written,
and take useless votes (IMHO) about it, or we can write the code.
What we should not do... is whine about others not writing the code
for us.
Putting the whine on a mailing list, or a wiki, or twitter, or IRC, or
<whatever> won't change that.
-Ronabop
Hi!
That is subjective. And even with a threaded client, if there are 80+
new messages then the call for vote is drowned out. Requiring
There was never 80+ new messages on different topics on the list. There
are 3-4 topics max, if you not count commit messages. Each of them can
contain dozens of messages, but those can be easily grouped.
something like [VOTE] in the subject helps, as then you can set-up a
[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :) I'll try to get it set up
ASAP and see how it works, before announcing the vote. It looks good in
description at least.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :) I'll try to get it set up ASAP
and see how it works, before announcing the vote. It looks good in
description at least.
Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :) I'll try to get it set up ASAP
and see how it works, before announcing the vote. It looks good in
description at least.Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.
I'm hopeful people will continue to understand the RFC definition:
- RFC: Request For Comments
And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached.
Also, people should be given a reasonable opportunity to offer an alternative RFC.
Regards,
Philip
Speaking generally, consensus is a dangerous and impossible standard. Few things can cripple progress like waiting for consensus. Voting may be one good way to move things forward without deadlocking forever. I agree though that without clear rules for how the process should work, voting is also chaotic. (Who can call for a vote? How? When is it final? Who can vote? How do they vote? How much is each vote worth? Is a simple majority or super majority needed?)
John Crenshaw
Priacta, Inc.
-----Original Message-----
From: Philip Olson [mailto:philip@roshambo.org]
Sent: Saturday, June 04, 2011 9:30 AM
To: Pierre Joye
Cc: Stas Malyshev; Derick Rethans; PHP Internals
Subject: Re: [PHP-DEV] Re: Voting does not belong on the wiki! (Was: [PHP-DEV] 5.4 moving forward)
[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :) I'll try to get it set up ASAP
and see how it works, before announcing the vote. It looks good in
description at least.Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.
I'm hopeful people will continue to understand the RFC definition:
- RFC: Request For Comments
And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy. Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached.
Also, people should be given a reasonable opportunity to offer an alternative RFC.
Regards,
Philip
hi Philip,
- RFC: Request For Comments
Thanks for the reminder. But RFC got approved at some point as well.
See the numerous W3C RFCs for some known examples.
And while doing so, not revert to a vote (RFV?) simply because discussing a topic can get messy.
What got messy? That instead of simply rejecting the RFC instead of
constantly adding new ideas to the stack. It is a perfectly valid flow
to block a RFC because it is considered as not well designed, not
desired or simple not fully compliant. It happened many times in php
in the past and in other projects as well.
Voting has clear winners and losers with potential loss for improvements. That and you must then worry about who can and cannot vote (i.e., non-inclusive community). It's rare that we've required a formal vote, so I fear we will now implement voting at inappropriate times rather than allow a consensus to be reached.
I'm sorry to not be powerful enough to achieve my ultimate goal, have
the most open processes and decissions in the OSS world within PHP.
That is, to include the communities in the decision processes and not
only to propose things.
Now you can keep arguing that voting is pointless, unfair, that
consensus can be reached easily, etc. etc. What we see is a total
different picture which is more related to dictatorial decisions or
puchists. None of these ways are good.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :) I'll try to get it set up
ASAP and see how it works, before announcing the vote. It looks good
in description at least.Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.I'm hopeful people will continue to understand the RFC definition:
- RFC: Request For Comments
And while doing so, not revert to a vote (RFV?) simply because discussing a
topic can get messy. Voting has clear winners and losers with potential loss for
improvements. That and you must then worry about who can and cannot vote
(i.e., non-inclusive community). It's rare that we've required a formal vote, so I
fear we will now implement voting at inappropriate times rather than allow a
consensus to be reached.Also, people should be given a reasonable opportunity to offer an alternative
RFC.
I agree wholeheartedly with Philip - and that does not mean that my intention is to derail a healthy voting process.
Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on.
First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion.
For this reason, I propose the following:
- There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote.
- The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time.
- Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed.
- In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned.
Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do.
Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great.
Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do.
If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever.
Zeev
Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on.
Fully agreed and it was the case for the array stuff and a consensus
is clear here, and in favour of one the proposals. To make the point
straight.
First, we need to make sure that the RFC is properly evaluated by the members of internals@, and that there's enough time for the RFC to be discussed here on the list. As Philip pointed out - an RFC is request for comments, not a request for a vote. This list isn't supposed to become some sort of a bureaucratic voting body, but where new ideas are discussed, refined, and eventually - accepted or rejected. I realize that some here are worried that discussions can be endless, but we shouldn't go for the other extreme of having no discussion.
Right, that's why we have draft, on discussions status and we should
add a vote status. Maybe clearly document that as well on the main
RFCs page to avoid badly proposed RFC to end in a voting phase too
early or at all.
- There'd be a minimum amount of time between when an RFC is brought up on this list and when it's voted on (say 2wks). The effective date will not be when the RFC was published on wiki.php.net/rfc - but when it was announced on internals@, by the author, with the intention of voting on it. It doesn't matter if the RFC was up there for 2yrs, or discussed 20 times in the past - if the intention is to go for a vote, there needs to be time for a healthy discussion, as opposed to just yes/no. This will also allow for people who are attending conferences, are on vacations, etc. - not to miss an entire discussion/vote.
Agreed.
- The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time.
Afaict, it is the case already.
- Eventually, it'll be up to the author to move ahead and call a vote on the RFC. That means that if the author feels that there's still healthy discussion going on, he can decide not to move ahead to request a vote after 2wks, but after 3 or 4wks. On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed.
- In my opinion, only RFCs with active proposers should be discussed. If the proposer of an RFC is no longer leading the effort to get this RFC accepted - it should either find a new proposer, or it should be abandoned.
Yes, the authors should have the hand on the process, not some random
not related developers, while anyone could be able to help to push an
idea.
Secondly - the announcement of the vote - I very much agree with Derick that having someone announce a vote in a thread of 50 messages (or even 10) messages is impractical. It needs to be a separate thread, and it has to be clearly marked - a simple subject prefix like [VOTE] followed by the title of the RFC should do.
Agreed.
Thirdly, there's the voting mechanism itself. The voting experience has to be nicer than editing a wiki page, I think we all agree about that... The plugin Stas installed gets us something better than that, but ideally, if we could provide single-click URLs in the [VOTE] email itself for voting yay or nay that would be great.
It is the case now. We have a poll plugin installed. To be proven to
fulfill our needs but as far as I remember, moodle2 does the job
pretty well.
Last, we need a predefined time for voting. It too has to be sufficiently long so that everyone has a chance to cast their votes, and on the other end shouldn't be endless. I think the 1wk should do.
Again, agreed. Deciding things between Friday evening and Monday
morning is simply not possible nor correct, for example.
If there's anybody who feels that the minimum 3wks period is too slow, it isn't. Any mistake we make can take a decade to fix, because downwards compatibility is such an important factor in PHP's design goals. Taking a bit of time to discuss the merits and contents of each RFC is well worth it, especially if we have rules and predefined schedules - so that discussions can't drag forever.
Even more true for languages related RFCs, they are critical (and
irreversible) and we should proceed with much caution than anything
else.
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on.
Fully agreed and it was the case for the array stuff and a consensus
is clear here, and in favour of one the proposals. To make the point
straight.
Say what?
Do people even know what they were voting for?
I have absolutely no idea whatsoever what is being voted on, so I haven't yet.
- The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time.
Afaict, it is the case already.
Definitely not.
There is so much discussion about the array stuff now that I have no
idea what is being voted on.. People started counting votes before the
discussion even began.
-Hannes
On Sun, Jun 5, 2011 at 5:46 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Some of you may have followed the twitter conversation that Pierre and I had at the end of last week; In my opinion, this dry (or partially wet) run that we had in the last few days of a voting process pointed to several deficiencies that need to be addressed in the RFC release process that need to be addressed before we move on.
Fully agreed and it was the case for the array stuff and a consensus
is clear here, and in favour of one the proposals. To make the point
straight.Say what?
Do people even know what they were voting for?
I have absolutely no idea whatsoever what is being voted on, so I haven't yet.
If you do not understand what has been discussed and can't vote,
that's not my or our problem. Nothing I can do will help you here.
- The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC. Again, the effective date will start from the time this email is sent to the list, not any other time.
Afaict, it is the case already.
Definitely not.
There is so much discussion about the array stuff now that I have no
idea what is being voted on.. People started counting votes before the
discussion even began.
Please, and I mean it, stop to state wrong and misleading information.
There is a page where people votes and have changed their votes,
https://wiki.php.net/rfc/shortsyntaxforarrays/vote. There is a clear
and obvious consensus, like or not.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.
This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt.
So does this require a new RFC, or do the RFC proposers feel this is a key concept?
Regards,
Philip
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt.
So does this require a new RFC, or do the RFC proposers feel this is a key concept?
As I stated before, there is a RFC with a fair amount of developers
involved. Some of the supporters of the Ubuntu TLS model already
changed their mind (as it clearly does not work for php, random
features being TLS just because of the timing makes no sense). If you
think a RFC is not ready, not desired, not good enough or whatever
other reason motivates you, vote against and propose something else.
But you can even say no and propose nothing afterwards.
As of this specific RFC, it is actually a very good one, it is not
perfect and will need adjustement in the coming years, that's a damned
sure thing. But we can not argue forever only because a minority
thinks we should argue endlessly or change nothing.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt.
So does this require a new RFC, or do the RFC proposers feel this is a key concept?
As I stated before, there is a RFC with a fair amount of developers
involved. Some of the supporters of the Ubuntu TLS model already
changed their mind (as it clearly does not work for php, random
features being TLS just because of the timing makes no sense). If you
think a RFC is not ready, not desired, not good enough or whatever
other reason motivates you, vote against and propose something else.
But you can even say no and propose nothing afterwards.
I agree. People should stick to the RFC system to hve a documented way of
saying what they like and what not. If the RFC writers want to adopt a change
that's their things. So far there is no reason to change it.
As of this specific RFC, it is actually a very good one, it is not
perfect and will need adjustement in the coming years, that's a damned
sure thing. But we can not argue forever only because a minority
thinks we should argue endlessly or change nothing.
Yes. The Release RFC is nothing that needs Backward compatbility. We should
vote on the general direction instead of fighting over a minor details
and getting nothing done. Details can be modified with later RFCs.
Hi!
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.This is a prime example of what we're talking about. Several have expressed a desire to follow an Ubuntu style of branching instead of the style proposed in said RFC. This is a core issue, so the RFC is certainly not ready to adopt.
So does this require a new RFC, or do the RFC proposers feel this is a key concept?
I think that this RFC does not contain Ubuntu-style LTS and it doesn't
look like it's author(s) support it, so it should be some different
point, which may be RFCed and voted on if we see substantial support for it.
Speaking of which, I personally don't understand how LTS thing would
work in PHP. Does it mean we'd decide out of the blue that some version
would have extended support, upfront? Like, say, we now say "5.5 would
have extended support"? Why would we want to do this, how would we know
it? E.g., I understand if we had an option of extending support for some
version post-factum, e.g., somewhere in 2015 we'd say "5.4 is so damn
good and 5.5 has so many substantial changes that now we want 5.4
support to be extended another couple of years, and we feel we have
people that are willing to do it". We could then talk on it and decide
it, nothing prevents it. But as I understand LTS model means we'd have
to decide it now, in 2011, and I don't see how it works. Could some of
the proponents on this model explain it?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev wrote:
Speaking of which, I personally don't understand how LTS thing would
work in PHP.
Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply because
pushing 5.3 caused problems/complaints from users due to the nature of the
changes. While that almost certainly is due to the poor way that the some of the
moves were documented, a version of 5.2 is still a preferred base for some? And
this should perhaps be viewed as the current LTS branch? Certainly for windows
users it IS a natural stable point! I've not looked to see what LTS Linux
distributions have frozen at, but essentially that is their own choice to manage
anyway? There is nothing in the current 5.2 base that would preclude previous
PHP5 code being borough forward to 5.2, but certainly in my own case, moving
that code TO 5.3 'clean' ready to further develop IS currently a stopper.
PHP5.1.7 was MY previous freeze point as that fixed a major bug in the Firebird
extension, but I only needed very minor tweaks to make all sites happy on the
latest PHP5.2. MY main stumbling block here is 'register_globals' as as the code
has been around for several years, and while not essential to remove while
running 5.3, this IS a natural break point to force a rewrite of the core system
to remove the reliance on it. That and having to support legacy windows servers ...
Moving forward, the point at which an LTS-PHP5.2 is replaced by a newer 5.x is
perhaps something that can't be dictated now? The main problem here is the lack
of a PHP6 branch which PHP5.3 was a sort of 'son of' development. As with PHP4,
some sections of users will simply not bother to change what they are using
anyway, so for them, which ever version they use is an 'LTS' so an official LTS
really is just a point at which major work MAY be required to switch over, so
that is the point at which dropping PHP5.2.LTS needs to be considered? Can
anybody make a case for anything earlier being the current LTS base?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
changes. While that almost certainly is due to the poor way that the some of the
moves were documented, a version of 5.2 is still a preferred base for some? And
this should perhaps be viewed as the current LTS branch? Certainly for windows
But
a) it is not, since we don't support it. Somebody else could do the
support, backport patches, etc. - but as far as PHP group is considered,
this version is not supported anymore and nobody has any desire to do it
as far as I know.
b) we certainly couldn't know anything about it in 2006 when we released
5.2.
of a PHP6 branch which PHP5.3 was a sort of 'son of' development. As with PHP4,
some sections of users will simply not bother to change what they are using
anyway, so for them, which ever version they use is an 'LTS' so an official LTS
really is just a point at which major work MAY be required to switch over, so
that is the point at which dropping PHP5.2.LTS needs to be considered? Can
anybody make a case for anything earlier being the current LTS base?
They can lag on any version that works for them, that's fine and if it
works for them, great. However I don't see how it explains how we can
declare any random version of PHP LTS upfront. If it's a new version,
they won't upgrade to it anyway, so that doesn't help neither them not
us, and if they're ready to upgrade, they could upgrade to any regular
version and stick with it they same way they do now.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev wrote:
changes. While that almost certainly is due to the poor way that the
some of the
moves were documented, a version of 5.2 is still a preferred base for
some? And
this should perhaps be viewed as the current LTS branch? Certainly for
windowsBut
a) it is not, since we don't support it. Somebody else could do the
support, backport patches, etc. - but as far as PHP group is considered,
this version is not supported anymore and nobody has any desire to do it
as far as I know.
b) we certainly couldn't know anything about it in 2006 when we released
5.2.
Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users
it IS the only available version. Changing the rest of the infrastructure to
support PHP5.3 builds of windows is not just a matter of changing the PHP
package! So while PHP may have washed it's hands of the problem, those users who
are stuck in the hole still need to be supported in some way. But all that is
being asked for is security fixes which seem to be a LOT less of a problem
nowadays anyway? So support IS just a matter of maintaining availability to it
and the correct builds of extensions that go with it.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Stas Malyshev wrote:
changes. While that almost certainly is due to the poor way that the
some of the
moves were documented, a version of 5.2 is still a preferred base for
some? And
this should perhaps be viewed as the current LTS branch? Certainly for
windowsBut
a) it is not, since we don't support it. Somebody else could do the
support, backport patches, etc. - but as far as PHP group is considered,
this version is not supported anymore and nobody has any desire to do it
as far as I know.
b) we certainly couldn't know anything about it in 2006 when we released
5.2.Currently off the shelf, 5.2.17 is the 'old stable' but for some windows
users it IS the only available version. Changing the rest of the
infrastructure to support PHP5.3 builds of windows is not just a matter of
changing the PHP package!
There is no reason not to update, absolutely none.
So while PHP may have washed it's hands of the
problem, those users who are stuck in the hole still need to be supported in
some way. But all that is being asked for is security fixes which seem to be
a LOT less of a problem nowadays anyway? So support IS just a matter of
maintaining availability to it and the correct builds of extensions that go
with it.
No it is not only about these rather simple tasks, really not. QA,
testing, etc. require consequent efforts, from many different teams.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 06.06.2011 12:46, schrieb Pierre Joye:
There is no reason not to update, absolutely none.
There is: http://bugs.php.net/bug.php?id=49189
Which "fixes" the issue by removing a feature and introducing a BC-Break.
You cannot say that any kind of bugs prevent the waste majority to
update from a dead cow to the current stable branch. And I'm not sure
if it is actually a bug or a badly documented setting.
Am 06.06.2011 12:46, schrieb Pierre Joye:
There is no reason not to update, absolutely none.
There is: http://bugs.php.net/bug.php?id=49189
Which "fixes" the issue by removing a feature and introducing a BC-Break.--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 06.06.2011 13:41, schrieb Pierre Joye:
You cannot say that any kind of bugs prevent the waste majority to
update from a dead cow to the current stable branch. And I'm not sure
if it is actually a bug or a badly documented setting.
Its not the bug that prevents moving forward but the fix of it!
[2009-08-07 07:40 UTC] jani@php.net
Obviously the documentation is wrong, it's PHP_INI_SYSTEM in sources
since fix of bug #43227 for PHP 5.2.7.
The fix of bug #43227 changed the setting from PHP_INI_PERDIR to
PHP_INI_SYSTEM, which is not a fix but a workaround for something
(ereg), which will probably be removed in the future and already is
deprecated.
Pierre Joye wrote:
Stas Malyshev wrote:
changes. While that almost certainly is due to the poor way that the
some of the
moves were documented, a version of 5.2 is still a preferred base for
some? And
this should perhaps be viewed as the current LTS branch? Certainly for
windowsBut
a) it is not, since we don't support it. Somebody else could do the
support, backport patches, etc. - but as far as PHP group is considered,
this version is not supported anymore and nobody has any desire to do it
as far as I know.
b) we certainly couldn't know anything about it in 2006 when we released
5.2.Currently off the shelf, 5.2.17 is the 'old stable' but for some windows
users it IS the only available version. Changing the rest of the
infrastructure to support PHP5.3 builds of windows is not just a matter of
changing the PHP package!
There is no reason not to update, absolutely none.
If you can convince the IT departments of some of the archaic council sites I am
having to deal with that they do not have to stress test every part of a new
system ... It's exactly the same argument FROM them as you are giving below as
to why we should NOT provide support!
Fortunately the problem is being eased by the replacement of the legacy windows
systems with Linux servers but that is still slow going in some customer sites.
In my own case since there is no external access I don't have to worry about
security issues anyway so perhaps the discussion is academic, but I can't
believe that I am the only person seeing this problem.
So while PHP may have washed it's hands of the
problem, those users who are stuck in the hole still need to be supported in
some way. But all that is being asked for is security fixes which seem to be
a LOT less of a problem nowadays anyway? So support IS just a matter of
maintaining availability to it and the correct builds of extensions that go
with it.
No it is not only about these rather simple tasks, really not. QA,
testing, etc. require consequent efforts, from many different teams.
I think all I am asking for is that the various elements of PHP5.2.17 are more
readily accessible directly from the PHP site, rather than having to scout
around for things like the pecl extensions on third party sites. Perhaps I just
need to push a current set of files onto my own site.
This does parallel the discussion on 'bundling' extensions, and simplifying
things so that individual extensions can be managed and even updated without
having to update the whole of the rest of the core.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
If you can convince the IT departments of some of the archaic council sites
I am having to deal with that they do not have to stress test every part of
a new system ... It's exactly the same argument FROM them as you are giving
below as to why we should NOT provide support!
Fortunately the problem is being eased by the replacement of the legacy
windows systems with Linux servers but that is still slow going in some
customer sites.
There is zero difference, windows or linux does not matter at the
language level. If they don't want to migrate to 5.3, win or linux
does not matter.
Anyway, that's off topic :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
If you can convince the IT departments of some of the archaic council sites
I am having to deal with that they do not have to stress test every part of
a new system ... It's exactly the same argument FROM them as you are giving
below as to why we should NOT provide support!
Fortunately the problem is being eased by the replacement of the legacy
windows systems with Linux servers but that is still slow going in some
customer sites.
There is zero difference, windows or linux does not matter at the
language level. If they don't want to migrate to 5.3, win or linux
does not matter.Anyway, that's off topic:)
What makes you say that - has PHP5.3 suddenly started working with production
releases of Apache on windows? Some site will not use third party builds which
is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is available to run
with a stock install of Apache.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Pierre Joye wrote:
If you can convince the IT departments of some of the archaic council
sitesI am having to deal with that they do not have to stress test every
part of
a new system ... It's exactly the same argument FROM them as you are
giving
below as to why we should NOT provide support!
Fortunately the problem is being eased by the replacement of the
legacy
windows systems with Linux servers but that is still slow going in
some
customer sites.There is zero difference, windows or linux does not matter at the
language level. If they don't want to migrate to 5.3, win or linux
does not matter.Anyway, that's off topic:)
What makes you say that - has PHP5.3 suddenly started working with
production releases of Apache on windows? Some site will not use third party
builds which is the WHOLE problem of PHP5.3 on windows ... only PHP5.2 is
available to run with a stock install of Apache.
Lester,
We use apache and 5.3 smoothly and with the recent addition of rwlock
in apc on windows, it runs even better and faster.
I'm sorry but unless you provide bugs report with clear reproduce
where we can actually try to help you, there is no chance to get
anywhere with this kind of discussions.
Now I would suggest to use bugs.php.net to report any issue you have
on apache on windows with PHP.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
We use apache and 5.3 smoothly and with the recent addition of rwlock
in apc on windows, it runs even better and faster.I'm sorry but unless you provide bugs report with clear reproduce
where we can actually try to help you, there is no chance to get
anywhere with this kind of discussions.Now I would suggest to use bugs.php.net to report any issue you have
on apache on windows with PHP.
Does that include reporting windows.php.net pages?
http://windows.php.net/download/ at the present time this is very clearly
directing users that they have to use VC6 builds for Apache and they are only
provided for PHP5.2.17
WE recommend using Apachelounge builds of apache, but some sites simply will
not use that as it is not the recommended build from Apache. They religiously
follow the rules printed on the official distributions and the download page is
an official document as far as they are concerned, so they are being told to use
VC6 builds. Apachelounge is not considered an official apache site :(
If the situation has now changed where is this documented? "Do NOT use VC9
version with apache.org binaries" is very clearly stated on the download page.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Pierre Joye wrote:
We use apache and 5.3 smoothly and with the recent addition of rwlock
in apc on windows, it runs even better and faster.I'm sorry but unless you provide bugs report with clear reproduce
where we can actually try to help you, there is no chance to get
anywhere with this kind of discussions.Now I would suggest to use bugs.php.net to report any issue you have
on apache on windows with PHP.Does that include reporting windows.php.net pages?
http://windows.php.net/download/ at the present time this is very clearly
directing users that they have to use VC6 builds for Apache and they are
only provided for PHP5.2.17WE recommend using Apachelounge builds of apache, but some sites simply
will not use that as it is not the recommended build from Apache. They
religiously follow the rules printed on the official distributions and the
download page is an official document as far as they are concerned, so they
are being told to use VC6 builds. Apachelounge is not considered an official
apache site :(
There is no official binaries for apache, please understand once and
for all and get over it. Apachelounge are well trusted builds using a
modern compilers and the offical Apache sources.
If the situation has now changed where is this documented? "Do NOT use VC9
version with apache.org binaries" is very clearly stated on the download
page.
And that's still true. But that has nothing to do with Apache or PHP
being not stable but CRT compatibilities. In any case, if you find any
bug, please report them at bugs.php.net, but that's totally unrelated
to this thread.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
WE recommend using Apachelounge builds of apache, but some sites simply
will not use that as it is not the recommended build from Apache. They
religiously follow the rules printed on the official distributions and the
download page is an official document as far as they are concerned, so they
are being told to use VC6 builds. Apachelounge is not considered an official
apache site:(There is no official binaries for apache, please understand once and
for all and get over it. Apachelounge are well trusted builds using a
modern compilers and the offical Apache sources.
????
http://httpd.apache.org/download.cgi
Win32 Binary IS one of the few binaries Apache supply!!! Some government sites
will ONLY allow that version to be installed :(
PHP5.2 installs have then been approved for use with the official apache
install, so are you saying we need to go back to even earlier builds of PHP5.2
to work with this?
If the situation has now changed where is this documented? "DoNOT use VC9
version with apache.org binaries" is very clearly stated on the download
page.
And that's still true. But that has nothing to do with Apache or PHP
being not stable but CRT compatibilities. In any case, if you find any
bug, please report them at bugs.php.net, but that's totally unrelated
to this thread.
See point above ... with the current windows situation on windows.php.net,
PHP5.2.17 is the last version of php available to go with the official windows
binaries from Apache? TESTING PHP5.3 on an official apache build and reporting
bugs is not the problem here, since users are told not to use them at all.
Since official apache builds have always worked stably for years with an
'official' build of PHP people simply expect that to continue!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
????
http://httpd.apache.org/download.cgi
Win32 Binary IS one of the few binaries Apache supply!!! Some government
sites will ONLY allow that version to be installed :(
PHP5.2 installs have then been approved for use with the official apache
install, so are you saying we need to go back to even earlier builds of
PHP5.2 to work with this?
I will repeat it a last time here, as I told it too many times
already, including to you. These binaries are convenience builds and
are by no mean official builds. That's not my word but the apache's
guys.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
????
http://httpd.apache.org/download.cgi
Win32 Binary IS one of the few binaries Apache supply!!! Some government
sites will ONLY allow that version to be installed:(
PHP5.2 installs have then been approved for use with the official apache
install, so are you saying we need to go back to even earlier builds of
PHP5.2 to work with this?
I will repeat it a last time here, as I told it too many times
already, including to you. These binaries are convenience builds and
are by no mean official builds. That's not my word but the apache's
guys.
Please can you provide a link where THAT statement is made!
The download page only makes reference to checking the security of a download by
checking the signatures, and it is this level of security that is used is a
statement that any of the downloads are 'clean' from what ever mirror source
they are downloaded from. There is nothing on
http://apache.favoritelinks.net//httpd/binaries/win32/README.html that says that
the windows builds are anything other than approved distributions of the current
builds of apache. Installation note for WAP have pointed new users to start with
the apache download for MANY years so that is where new users will always start,
and when an update is released, windows users are redirected once again to the
download page.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Please can you provide a link where THAT statement is made!
Chech the php windows internals list archive as well as the httpd
devel ones. This statement has been written numerous times in both
lists.
Pierre Joye wrote:
Please can you provide a link where THAT statement is made!
Chech the php windows internals list archive as well as the httpd
devel ones. This statement has been written numerous times in both
lists.
PERHAPS such important information could be made available to REAL USERS? There
has never been any public statement to that effect!
Until you came on the scene I had never even had to look at compiling anything
in the FWAP or FLAP stack, everything just worked from the precompiled downloads
linked to by the tutorials. EVEN the php manual STILL starts a windows apache
install with a download of the .msi from apache! That is one of the first hit on
google and bing for "install apache php on windows" and every one of the links I
checked starting with Drupal say "Download the Apache Windows MSI Installer from
Apache.org". I've updated my own FWAP installation tutorial to use the
Apachelounge installer but one has to go a long way down the google or bing
results to find any reference to apachelounge at all :(
So a few people saying that this is not an official version of Apache makes no
difference to the probably millions of users who follow the directions to
install Apache and then find problems adding PHP to it ... and start asking
'where is the VC6 version of PHP5.3' everywhere other than on the PHP lists.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
PERHAPS such important information could be made available to REAL USERS?
There has never been any public statement to that effect!
For the 10th time, please stop to uppercase every 2nd word.
Until you came on the scene I had never even had to look at compiling
anything in the FWAP or FLAP stack,
After months of endless discussions, the reasons why we stop to
support a 16 years old compiler (please notice the "we", not the "I")
are still black magic to your eyes. I'm sorry that I did not succeed
to explain it better.
However I ask you, strongly, now to stop to pollute this thread with
totally unrelated topics. Thanks for your understanding.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
However I ask you, strongly, now to stop to pollute this thread with
totally unrelated topics. Thanks for your understanding.
This is something of a rather important point since PHP has always been very
strongly related to Apache so it is totally related to a discussion of moving
PHP forward. Currently the mainstream information is so far adrift of the
present situation that at it needs to be addressed. A starting point would be to
bring all of the PHP manual information in line with the current situation and
point people to the preferred installation paths rather than telling people to
use steps that do not actually get to a working PHP5.3 setup? And starting to
push out 5.4 will increase peoples requests to getting things working with
exiting windows/apache/php5.2 setups.
Does anybody other than Pierre disagree with the point that currently the
mainstream windows installation paths are something of a mess and needs to be
updated in some way?
I've been updating my own installation guides, but I had not realised just how
many other PHP projects provide windows installation guides that no longer work.
Not having been using windows myself on new builds for some time, I had not
updated and tested clean installs and it's only recently I've found how out of
date things are :( I've been getting emails from people asking why my guides
were not working hence the need to address this and get back to a working situation.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Pierre Joye wrote:
????
http://httpd.apache.org/download.cgi
Win32 Binary IS one of the few binaries Apache supply!!! Some
government
sites will ONLY allow that version to be installed:(
PHP5.2 installs have then been approved for use with the official
apache
install, so are you saying we need to go back to even earlier builds
of
PHP5.2 to work with this?I will repeat it a last time here, as I told it too many times
already, including to you. These binaries are convenience builds and
are by no mean official builds. That's not my word but the apache's
guys.Please can you provide a link where THAT statement is made!
The download page only makes reference to checking the security of a
download by checking the signatures, and it is this level of security that
is used is a statement that any of the downloads are 'clean' from what ever
mirror source they are downloaded from. There is nothing on
http://apache.favoritelinks.net//httpd/binaries/win32/README.html that
says that the windows builds are anything other than approved distributions
of the current builds of apache. Installation note for WAP have pointed new
users to start with the apache download for MANY years so that is where new
users will always start, and when an update is released, windows users are
redirected once again to the download page.
you can read more about this here:
http://osdir.com/ml/php-windows/2011-04/msg00023.html
especially this:
http://marc.info/?l=apache-httpd-dev&m=129646769502349&w=2
Tyrael
Hi!
Currently off the shelf, 5.2.17 is the 'old stable' but for some windows users
it IS the only available version. Changing the rest of the infrastructure to
5.2.17 is unsupported. It is announced on php.net. Now, some Windows
users, due to certain choices, may have to run this version - but this
doesn't change the fact it's officially unsupported. So I don't see how
it supports viability of LTS idea.
package! So while PHP may have washed it's hands of the problem, those users who
are stuck in the hole still need to be supported in some way. But all that is
There's nothing to prevent anybody willing to do it from providing this
support. However, the question is not if there are users with some
special needs. The question is LTS, specifically:
- Will PHP group ever willing to support a version in LTS timeframe -
so far it never happened - How we know we'd need to support such version UPFRONT - before it's
released?
being asked for is security fixes which seem to be a LOT less of a problem
nowadays anyway? So support IS just a matter of maintaining availability to it
and the correct builds of extensions that go with it.
It looks to me you are confusing the question of "is LTS a viable model
for PHP development" with "if we had LTS 5 years ago, would somebody
benefit from it now". These are two different questions, and the second
one is pure theoretical since we didn't and still haven't and I for one
still don't understand how we could have it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Currently off the shelf, 5.2.17 is the 'old stable' but for some
windows users
it IS the only available version. Changing the rest of the
infrastructure to5.2.17 is unsupported. It is announced on php.net. Now, some Windows
users, due to certain choices, may have to run this version - but this
doesn't change the fact it's officially unsupported. So I don't see
how it supports viability of LTS idea.
Yes, and one week after support ending with announcement of 5.2.15,
5.2.16 was released again claiming that support has ended. And then a
month later 5.2.17 was released, but no longer mentions that support has
ended. Not too surprising then if people incorrectly assume that
critical issues will continue to be fixed for 5.2.
package! So while PHP may have washed it's hands of the problem,
those users who
are stuck in the hole still need to be supported in some way. But all
that isThere's nothing to prevent anybody willing to do it from providing
this support. However, the question is not if there are users with
some special needs. The question is LTS, specifically:
- Will PHP group ever willing to support a version in LTS timeframe -
so far it never happened
5.2 was supported for about 5 years, which is what one would expect from
an LTS release, so yes. It has effectively already happened.
- How we know we'd need to support such version UPFRONT - before it's
released?
Because you say upfront how long the release will be supported. This is
fairly straight-forward for any project using timed releases, which by
the looks of it, is what the RFC is suggesting.
How does Canonical know which Ubuntu release will be LTS? Because they
decided every 4th release will be LTS. It's really not any more
complicated than that.
Maybe confusion is because in the past PHP has not followed timed
releases, so there's no knowing how long it will be until the next
version comes out. The best you can do then is promise x months of
support after the next version is released.
being asked for is security fixes which seem to be a LOT less of a
problem
nowadays anyway? So support IS just a matter of maintaining
availability to it
and the correct builds of extensions that go with it.It looks to me you are confusing the question of "is LTS a viable
model for PHP development" with "if we had LTS 5 years ago, would
somebody benefit from it now". These are two different questions, and
the second one is pure theoretical since we didn't and still haven't
and I for one still don't understand how we could have it.
Not intentionally, but 5.2 was supported for the time-frame expected
from an LTS release. That may have given the impression that 5.3 will be
supported for 5 years too, and therefore hosts can upgrade within a year
or two after the release and still expect to get updates for the next
3-4 years.
One thing that I think would help drive adoption of newer versions is
EOL being very clearly stated. As it stands we don't know if 5.3 will
continue to be supported for the next 5 years, or if it will be EOL next
year. All we have to go on is what's happened in the past, and although
5.2's lifetime was an anomaly, it seems it's what people have come to
expect.
Cheers,
David
Hi!
On Sun, Jun 5, 2011 at 5:52 PM, Philip Olsonphilip@roshambo.org
wrote:I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.This is a prime example of what we're talking about. Several have
expressed a desire to follow an Ubuntu style of branching instead
of the style proposed in said RFC. This is a core issue, so the RFC
is certainly not ready to adopt.So does this require a new RFC, or do the RFC proposers feel this
is a key concept?I think that this RFC does not contain Ubuntu-style LTS and it doesn't
look like it's author(s) support it, so it should be some different
point, which may be RFCed and voted on if we see substantial support
for it.Speaking of which, I personally don't understand how LTS thing would
work in PHP. Does it mean we'd decide out of the blue that some
version would have extended support, upfront? Like, say, we now say
"5.5 would have extended support"? Why would we want to do this, how
would we know it? E.g., I understand if we had an option of extending
support for some version post-factum, e.g., somewhere in 2015 we'd say
"5.4 is so damn good and 5.5 has so many substantial changes that now
we want 5.4 support to be extended another couple of years, and we
feel we have people that are willing to do it". We could then talk on
it and decide it, nothing prevents it. But as I understand LTS model
means we'd have to decide it now, in 2011, and I don't see how it
works. Could some of the proponents on this model explain it?
Theoretical benefits of LTS:
- You have a version that is supported for an extended period of time.
Possibly useful for Ubuntu LTS releases and RHEL and other distros that
have a >3 year lifetime. - Keeps disruptive changes coming in on an LTS release. The goal is
that LTS is the polished result of the prior non-LTS releases. - Makes hosting companies feel safer offering an LTS release as it
means less disruption for their users. - Businesses like it because it's less work for them to upgrade every
3-5 years instead of every 6-18 months.
Those are the ones I can think of.
Although I appreciate the model with my OS, I don't think it would work
well on the application/component level.
Cheers,
David
This is a prime example of what we're talking about. Several have
expressed a desire to follow an Ubuntu style of branching instead
of the style proposed in said RFC. This is a core issue, so the
RFC is certainly not ready to adopt.So does this require a new RFC, or do the RFC proposers feel this
is a key concept?I think that this RFC does not contain Ubuntu-style LTS and it
doesn't look like it's author(s) support it, so it should be some
different point, which may be RFCed and voted on if we see
substantial support for it.Speaking of which, I personally don't understand how LTS thing would
work in PHP. Does it mean we'd decide out of the blue that some
version would have extended support, upfront? Like, say, we now say
"5.5 would have extended support"? Why would we want to do this, how
would we know it? E.g., I understand if we had an option of
extending support for some version post-factum, e.g., somewhere in
2015 we'd say "5.4 is so damn good and 5.5 has so many substantial
changes that now we want 5.4 support to be extended another couple
of years, and we feel we have people that are willing to do it". We
could then talk on it and decide it, nothing prevents it. But as I
understand LTS model means we'd have to decide it now, in 2011, and
I don't see how it works. Could some of the proponents on this
model explain it?
The trunk development and the branching policy & process isn't
adequately captured in the RFC. This is a gray area that should be
included.
It's a pity little of the mail list discussion seems to have been
merged back to the RFC as clarifications, or in a comment & answer
section.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Hi!
Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.
I've installed voting plugin, see description here:
http://www.dokuwiki.org/plugin:doodle2
and example how it looks here at the end (login required to vote):
https://wiki.php.net/playground/playground
I think it'd work.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
right, that's the one I was willing to install as well, great that you
did it! Thanks :)
Hi!
Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.I've installed voting plugin, see description here:
http://www.dokuwiki.org/plugin:doodle2
and example how it looks here at the end (login required to vote):
https://wiki.php.net/playground/playground
I think it'd work.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
Please keep them in the wiki as we planed to do. THere are plugins and
it is very easy to manage, allows per section voting etc.I've installed voting plugin, see description here:
http://www.dokuwiki.org/plugin:doodle2
and example how it looks here at the end (login required to vote):
https://wiki.php.net/playground/playground
I think it'd work.
How does it work? Do you need write permission to the page it is
located on, or is it enough to have login?
How do you differentiate between 'core' and 'community' voting? (or is
that maybe not needed?)
-Hannes
Hi!
How does it work? Do you need write permission to the page it is
located on, or is it enough to have login?
Login's enough. There is also an ability to designate admins (see the
docs) which can edit the votes, but I'm not sure if it's needed for
user-based vote.
How do you differentiate between 'core' and 'community' voting? (or is
that maybe not needed?)
You can have votes by user (editable), by IP (then you have to say who
you are and can't edit the vote) or free-for-all no restrictions vote.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for votes.
That is subjective. And even with a threaded client, if there are 80+
new messages then the call for vote is drowned out. Requiring
something like [VOTE] in the subject helps, as then you can set-up a
filter. And if it's a requirement, every call without [VOTE] in the
subject is invalid. (Easy to fix if somebody forgot it as well). It
would expose this kind of thing.
Why not setup a different ML that is announce-only except a few people, just
to announce votes?
hi Derick,
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access
to wiki machine and I'll install it :)Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showing
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).
Please re consider your opinion like "noises on the list" and other
similar statements, thanks.
As of the votes in the wiki, it is perfectly fine and valid, easy to
manage and open. Much more easier than counting random votes in the
ML, especially when discussions are split in many threads. The
discussions and related activities do happen on the list and that's a
good thing.
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Martin Scotta
hi Derick,
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access
to wiki machine and I'll install it :)Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are showing
up just in the wiki then there is no exposure on the list and things are
easy to miss (especially with the huge amount of noise that's already on
the list).Please re consider your opinion like "noises on the list" and other
similar statements, thanks.As of the votes in the wiki, it is perfectly fine and valid, easy to
manage and open. Much more easier than counting random votes in the
ML, especially when discussions are split in many threads. The
discussions and related activities do happen on the list and that's a
good thing.
Yes, but only who has wiki karma are allowed to vote.
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
How about a separate email topic dedicated to voting?, that would reduce the
signal to noise ratio for votes (and increase it for opinions).
Regards,
David
On Fri, Jun 3, 2011 at 10:25 AM, Martin Scotta martinscotta@gmail.comwrote:
Martin Scotta
hi Derick,
I'd like to set up a vote for the undecided TODO features on
wiki.php.net, anybody could help me with setting up the voting module
there if there's such thing on the wiki? Or set me up with the access
to wiki machine and I'll install it :)Voting on the wiki? Yuck. If you want participation, do it here on the
mailinglist and store the record in the wiki. If all "votes" are
showing
up just in the wiki then there is no exposure on the list and things
are
easy to miss (especially with the huge amount of noise that's already
on
the list).Please re consider your opinion like "noises on the list" and other
similar statements, thanks.As of the votes in the wiki, it is perfectly fine and valid, easy to
manage and open. Much more easier than counting random votes in the
ML, especially when discussions are split in many threads. The
discussions and related activities do happen on the list and that's a
good thing.Yes, but only who has wiki karma are allowed to vote.
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org