auroraeosrose/gist:303dca30e29464a65bd9

## gistfile1.txt
PHP7 is coming

And it's breaking all of our extensions
There are currently more changes to the internal apis than there are to things that users will see (and there are enough of those)

In fact not even all the extensions in php source proper are all the way PHP7'd - most of PECL and extensions hosted elsewhere haven't even started!  Heck half don't have maintainers!

Extensions are also notorious for poor api design, poor testing, and non-existent docs
But they're also powerful, useful, and fast and more people should use them
PHP7 is coming - fast - and we have a chance to "break" things and to get the community interested and involved

It's time to make extensions first class citizens of the PHP community

The Go PHP7 (ext) has several goals
1. Get PHP extensions running "out of the box" when PHP7 is released (no lag time)
2. Make extensions in general easier to install and use (binaries, ppas)
3. Get more people involved in extension maintainance (and travis/appveyor running on them all, killing off bugs)
4. Get more documentation written for extension writing
5. Codify some of the "best practices" of extension writing and design (a la PSR)


So - how do we do this?
Any community project starts with people
First we need volunteers who can give time on a regular basis.  Not necessary a LOT of time, I'm starting with 30 minutes a day - your # may be more or less, but it's hard on less than 10 a day.  We need people who write PHP, we need people who write C or C++ (or want to learn it), we need people who are good at testing, at setting up ci environments, who can triage bugs and write tests for bugs reported.  Not everybody needs to be a master, there's a LOT of work to go around.
Second we need those people to communicate - probably on IRC (room location?) and maybe a place on github to dump documentation as it gets worked on, and keep each other and the project moving forward.  Sitting in a room all day with no feedback makes for stagnation, but "many hands make light work"
Finally we need people to work their 30 minutes a day - on extension code, documentation, testing, building, etc.

Actual "Todo" Roadmap
1. Catalog php extensions - from core, from pecl, from random other places, try to find ones people use or WANT to use (broken ones or proof of concepts included)
2. Look at their current status and maintainers - attempt to contact maintainers or find 1-2 new maintainers for EACH extension, fork those with recalcitrant or unresponsive owners (hurray open source)
3. Make it build on PHP7 (while writing down how it's done) - this is probably the hardest part, the part for people who want to learn extensions or know C to work on, - this includes brain dumps of best practices, things to watch out for,  how to migrate will help later folks get up to speed
4. Make it run RIGHT on PHP7 - this is more than just C code.... if they don't have tests, add tests, if they don't have docs, write docs, if their apis were designed 10 years ago and use resources and hurt you to touch them - redesign the apis, set up travis and appveyor(windows ci) so that they are continously tested, fix bugs that have been outstanding, add new features - keep the extensions alive and well
5. Get PECL, pickle, and composer all working together so that extensions are readily available as binaries, easily compilable for use with existing php installs, and a searchable discovery site for extensions - perhaps a larger scale pecl but more on the line of packagist with anything goes
	PHP7 is coming

	And it's breaking all of our extensions
	There are currently more changes to the internal apis than there are to things that users will see (and there are enough of those)

	In fact not even all the extensions in php source proper are all the way PHP7'd - most of PECL and extensions hosted elsewhere haven't even started! Heck half don't have maintainers!

	Extensions are also notorious for poor api design, poor testing, and non-existent docs
	But they're also powerful, useful, and fast and more people should use them
	PHP7 is coming - fast - and we have a chance to "break" things and to get the community interested and involved

	It's time to make extensions first class citizens of the PHP community

	The Go PHP7 (ext) has several goals
	1. Get PHP extensions running "out of the box" when PHP7 is released (no lag time)
	2. Make extensions in general easier to install and use (binaries, ppas)
	3. Get more people involved in extension maintainance (and travis/appveyor running on them all, killing off bugs)
	4. Get more documentation written for extension writing
	5. Codify some of the "best practices" of extension writing and design (a la PSR)


	So - how do we do this?
	Any community project starts with people
	First we need volunteers who can give time on a regular basis. Not necessary a LOT of time, I'm starting with 30 minutes a day - your # may be more or less, but it's hard on less than 10 a day. We need people who write PHP, we need people who write C or C++ (or want to learn it), we need people who are good at testing, at setting up ci environments, who can triage bugs and write tests for bugs reported. Not everybody needs to be a master, there's a LOT of work to go around.
	Second we need those people to communicate - probably on IRC (room location?) and maybe a place on github to dump documentation as it gets worked on, and keep each other and the project moving forward. Sitting in a room all day with no feedback makes for stagnation, but "many hands make light work"
	Finally we need people to work their 30 minutes a day - on extension code, documentation, testing, building, etc.

	Actual "Todo" Roadmap
	1. Catalog php extensions - from core, from pecl, from random other places, try to find ones people use or WANT to use (broken ones or proof of concepts included)
	2. Look at their current status and maintainers - attempt to contact maintainers or find 1-2 new maintainers for EACH extension, fork those with recalcitrant or unresponsive owners (hurray open source)
	3. Make it build on PHP7 (while writing down how it's done) - this is probably the hardest part, the part for people who want to learn extensions or know C to work on, - this includes brain dumps of best practices, things to watch out for, how to migrate will help later folks get up to speed
	4. Make it run RIGHT on PHP7 - this is more than just C code.... if they don't have tests, add tests, if they don't have docs, write docs, if their apis were designed 10 years ago and use resources and hurt you to touch them - redesign the apis, set up travis and appveyor(windows ci) so that they are continously tested, fix bugs that have been outstanding, add new features - keep the extensions alive and well
	5. Get PECL, pickle, and composer all working together so that extensions are readily available as binaries, easily compilable for use with existing php installs, and a searchable discovery site for extensions - perhaps a larger scale pecl but more on the line of packagist with anything goes