TLK: CVSROOT / avail
NEW: Call for Papers: International PHP Conference 2005 Spring Edition
NEW: PHP 4.3.10 and 5.0.3
TLK: Downloads cleanup
BUG: foreach() in PHP 4.3.10
PAT: Don’t forget –prefer-non-pic!
TLK: CVSROOT / avail
Jesper Veggerby Hansen, now one of the newest php.net account holders, wrote a
plaintive note asking whether anyone had managed to get a CVS account opened over
the last couple of months. Alan Knowles forwarded his note to the internals list,
together with a suggestion that the PHP Group should outsource the karma management
of PEAR stuff to one of PEAR Group.
Rasmus Lerdorf, who finds himself responsible for most of the ‘karma management’
on php.net, went through the backlog of applications for CVS access and added a
bunch of new accounts, alongside the following message:
<i>A lot of rejected accounts in this run. Some were clearly bogus,
others were way too vague. We should probably update the tool to let
us provide a rejection comment which in most cases would be, "Which
language project or which PEAR package" do you intend to work on.</i>
He also replied to Alan, saying that he’d love to outsource PEAR account
management, but that the administration tools would need modifying first.
Nuno Lopes, who evidently missed the last round of clearances, wrote suggesting
that the deletion of unused CVS accounts should also be on the agenda. He’d found
that 50% of phpdoc CVS accounts had never been used. Rasmus responded that this was
a lot less critical than the problem of getting new accounts ratified in the first
place. This really does tend to fall on his head, so if Rasmus is busy on a project
and you don’t happen to know anyone who is part of PHP Group, you can find yourself
waiting until his project’s finished before you’re able to commit your contribution.
As he said, having unused accounts sitting around is less of a problem.
Nuno made the point that “there are some guys that use their account like a
free e-mail account redirection” and accused Rasmus of offering accounts to
anyone who wanted to join, which isn’t actually true. Rasmus tries to verify the
request before creating a new account; this is why it’s generally best to have a
named ‘sponsor’ on a CVS application. It eases the verification process. Nuno then
suggested that there should be a votes system along the lines of the PePR proposal
system in PEAR. You could almost feel the rest of php.net engaging in a collective
shudder at this point, and Rasmus was quick to tag it as ‘work for the sake of
Olivier Hill made the point that unused accounts could be a security risk, but
noted that it would be difficult for an account holder to do much harm. He also
noted that there were some people that had been given php.net accounts purely so
that they could help maintain the user notes in the manual – these individuals will
never show up in any CVS-based statistics, because they don’t touch CVS itself.
Rasmus backed him; some have accounts but no karma, and others have accounts with
karma (e.g. for the phpdoc module) which they may or may not actively use. He added
that some translation teams consist of a small army of people who don’t do their own
commits; their work is checked by their editorial team, who take responsibility for
the CVS commits for the entire group. Those translators have CVS accounts, and may
also be working on notes maintenance. Trimming the account space is not a trivial
The last time I did it I used a combination of checking the cvs logs
for commits from accounts issued more than a year beforehand and
adding everyone who had never committed anything to a list. Then I
sent an email to everyone on the list asking them to confirm their
accounts and to update their account note to indicate what they were
using their account for. After a few weeks I then deleted everyone I
hadn't heard from and people who didn't provide a decent reason for
keeping their account.
It's probably time to do another such run.</i>
Olivier agreed that the voting system was a bad idea, both because it would
create more work for no good reason and because it relies on the concept of proof.
He also felt that further restrictions on new accounts would be an unwelcome
Sean Coates came up with some evidence
[dead link] that many – but not all – active notes maintainers do in fact use their
karmic CVS accounts.
Andi Gutmans agreed with the original premise of the thread, that PHP Group
should distribute the karma management load and allow sub-groups to handle the
various incoming account requests. He felt that this would allow php.net to be both
much more responsive and more selective. However, this would need to be backed by a
better administration tool than we currently have.
Wez Furlong agreed that having designated ‘karma crews’ for the sub-projects
would be a better approach than the current system. He felt that the biggest hurdle
in designing a new karma-granting interface on masterweb was that it resides on a
different box to CVS; the rest should be trivial.
Short version: A long-overdue cleanup on the karma-granting front is
NEW: Call for Papers: International PHP Conference 2005 Spring
Frank Stepan of the Software & Support Verlag sent a Call for Papers to the
internals list at the beginning of the week. The Amsterdam conference will be held
on May 2nd (pre-conference lectures), May 3rd and May 4th, and the streams are as
- General PHP
- PHP & Business/Integration
- PHP & Databases
- PHP Design
- PHP Extensions
- PHP & XML
Proposals for two 75-minute talks (per speaker) in these subject areas should be
submitted before January
7th. Speakers’ travel expenses and lodging will be covered, plus of course you get
to attend the rest of the conference and meet up with everybody from the European
end of PHP development.
Short version: Fresh blood required, please do apply.
NEW: PHP 4.3.10 and 5.0.3
Ilia Alshanetsky, as Release Master for the 4.3 series, had the unenviable task
of announcing an unusual dual-branch release on 15th December. His release message
is reprinted here in full:
<i>PHP Development Team would like to announce the immediate release of
PHP 4.3.10 and 5.0.3. These are maintenance releases that in addition
to non-critical bug fixes address several very serious security issues.
These include the following:
* CAN-2004-1018 - shmop_write() out of bounds memory write access
* CAN-2004-1018 - integer overflow/underflow in pack() and unpack()
* CAN-2004-1019 - possible information disclosure, double free and
negative reference index array underflow in deserialization code
* CAN-2004-1020 - addslashes not escaping