Contributing to the

PHP Internals Community

Rowan Collins - BrightonPHP - March 2017

Rowan Collins

  • Worked with PHP for over 10 years
  • Senior Developer / Architect at Holiday Taxis
  • Co-organiser of BrightonPHP
  • Rowan’s World Et Cetera - http://rwec.co.uk
  • IMSoP on GitHub and Stack Overflow
  • Stavron on Twitter

Please sign up to the mailing list so I can spam you! ;)

The Community

Who’s In Charge?

  • Nobody!
  • Meritocratic
  • Consensus-based
  • No “Benevolent Dictator”
  • Founders like Rasmus Lerdorf and Zeev Suraski are respected, but not in charge
  • People are paid to work on it, particularly at Zend Technologies

karma - permissions for various parts of php.net, including different parts of the codebase and the wiki

Occasional controversy when Zend work on things in secret, e.g. PHPNG

Committers and Extension Maintainers

Managing Releases

  • Release Managers (“RMs”) - usually two working together on each release
  • Mostly a co-ordinator role, occasionally judge what patches are “safe”
  • A new release every year, maintained for 2 years + 1 security only
  • PHP 5.6 has extended security support, but no more bug fixes!

Documentation

  • http://doc.php.net/tutorial/
  • A great way to contribute
  • Mostly a separate community
  • Has its own list to co-ordinate
  • Edit online at https://edit.php.net/
    • Use “Anonymous Login”, even after you authenticate with GitHub

Unofficial Channels

  • No official IRC channel
  • #php.pecl on EFNet
    • http://www.efnet.org/
  • Room 11 on Stack Overflow chat

The List

Also on Usenet!

List Etiquette

  • https://github.com/php/php-src/blob/master/README.MAILINGLIST_RULES
  • Formatting
    • Reply below (or inline with) your quote
    • Use plain text not HTML
  • Things can get heated
    • Lots of debate because there’s no President or Chair
    • “Keep your head when those around you are losing theirs”
  • Make sure you’ve thought your idea through
    • Make suggestions and offers, not demands
    • Listen and learn

“toxic kindergarten”

List Traffic

  • Average around 15 to 20 messages per day
  • 3 or 4 on-going threads
  • Don’t try to keep up with them all!
  • Use a mail client that lets you manage threads, and just let some pass you by

Thunderbird is great; GMail’s “conversations” not quite as flexible

Mailing List Posts Per Week

64-bit improvements

5.6 feature freeze

PHPNG

Naming 7.0

Code of Conduct

Annotations

The future of PEAR & PECL

Based on my own inbox. Labels are informed guesses.

PHPNG = the new Engine in PHP 7, developed at Zend Technologies

Mailing List Posts Per Week

Scalar Type Hints!

(“scalar type” or “STH” or “strict_types” or “strict mode”)

A very rough search by subject line, probably an under-estimate.

Other discussions were fall out from STH, e.g. over process.

The Code

There is a PHP Language Spec

  • https://github.com/php/php-langspec
  • Written for HHVM to test themselves against
  • Formally describes the latest version of PHP
  • The code distributed from php.net is still the official “PHP”

Where to begin?

  • It’s all in C - and there are A_LOT_OF_MACROS
  • Reference guides - most not yet updated for PHP 7 :(
  • lxr.php.net
    • Great for clicking through to definitions
    • When it’s working…
  • GitHub source browser
  • Build environment

Source Code Layout

  • ext/ – “Extensions”
  • tests
  • Zend/ – “The Engine”

Extensions

  • Even the most fundamental sets of classes and functions are “extensions”
  • ext/standard includes functions like strpos() and rand()
  • The “S” in SPL also means “Standard”, but that’s a different extension.
  • Extensions can also affect the engine, e.g. OpCache, XDebug

bundled / in core - part of official releases
PECL - maintained and released separately

72 extensions are currently bundled. Most can be disabled or built separately and loaded in php.ini

Extensions are moved between PECL and core based on importance, stability, or maintenance

Tests

  • Make sure you write and update them!
  • *.phpt files
  • Basically some PHP code with expected output
  • Each extension has its own tests directory

The Zend Engine

The basic structure the whole language runs on.

Also includes

  • Zend Memory Manager
  • ZTS (Zend Thread Safety) / TSRM (Thread Safe Resource Manager)

Source Code

Tokens

Abstract Syntax Tree

Execute

OpCodes

OpCache

What to look for

  • PHP_FUNCTION() and PHP_METHOD() mark implementation visible to userland
  • _php_foo is internal to an extension
  • php_foo is exposed to other extensions
  • zend_foo is exposed in the Engine
  • ZPP - Zend Parse Parameters - function or macros for checking and converting PHP function parameters

zval - the internal C struct that holds any PHP value

The Process

Bug Reports

  • http://bugs.php.net
  • For reporting bugs, and small feature requests
  • Not used for tracking projects
  • Anything complicated or controversial goes to Internals - and often an RFC
  • A lot of old tickets
  • Make sure it’s not documented behaviour, or an out of support version

Pull Requests

  • php-src on GitHub: https://github.com/php/php-src/pulls
  • Preferred way to suggest a patch for any bug or feature
  • Discussion of implementation happens here (e.g. coding style, missing or failing tests)
  • Deeper discussion on Internals
  • Has recently been de-cluttered

https://github.com/php/php-src/pull/1902

Significant Changes - The RFC Process

  • Managed on the wiki at https://wiki.php.net/rfc
  • Document past, current, and future proposals

RFC - Stands for “Request for Comments”, like Internet standards
The formal process of proposing and agreeing a change to PHP

RFC Process - Useful Links

When do you need an RFC?

  • Any change to the core language
  • A significant new feature in a bundled extension
  • A bug fix that means breaking something else
  • Removal or deprecation of existing functionality

BC - Backward Compatibility - always an important consideration
e.g. “BC break”, “maintain BC”, “non-BC”, etc

RFC Process - Drafting & Discussion

  • A single author “owns” the RFC
  • Discuss informally beforehand
  • Get wiki RFC karma, and draft based on the template
    • Exactly what will and won’t change
    • Impact on security, performance, other parts of the language
  • Formally announce
  • Listen to the feedback and update

‘+1’, ‘-1’, ‘I’m +1 on this’ - shorthand for agree / disagree
These are
not votes! Sometimes also ‘+0.5’, ‘-100’, etc

RFC Process - Voting

  • After at least 2 weeks, and once there’s nothing more to say
  • Uses a widget on the wiki
  • Small changes require 50%+1, but “language changes” require two thirds
  • Minimum one week, normally two
  • 30 to 40 regular voters, but many more can vote
    • Scalar Type Hints got 156 votes!
  • Reform often proposed, but tricky to agree

https://wiki.php.net/rfc/deprecate-bareword-strings

RFC Process - Implementation or Rejection

  • Implementation may precede vote, and be merged straight in
  • A few accepted RFCs sit “Awaiting Implementation” due to technical challenges
  • Ideally, “no” voters explain why on list, but doesn’t always happen
  • A rejected RFC may be referenced in a future proposal that addresses the concerns raised
  • Sometimes, the voting is halted early, and the RFC withdrawn to go back to the drawing board

See you on the list!