Stefan Jibrail Froelich - 2012-04-06 02:35:34
What is the use of integrating with Github if the core developers won't accept pull requests.
Granted, some decisions will have to be made, but allowing people to fork and offer patches is the whole idea of GH. If they won't accept requests, then they might as well have simply used a private repo.
That being said, I think the integration with GH is gonna breathe some freshness into Php. This might just be the best thing to happen to Php. Even obscure projects attract developers on GH.
Manuel Lemos - 2012-04-06 03:43:12 - In reply to message 1 from Stefan Jibrail Froelich
Right, just to make clear, Git and GitHub are not the same thing.
PHP has now its own Git repository and it is not on GitHub. What is on GitHub is a copy of the PHP main repository.
The integration with GitHub I suppose is just for making it easy for PHP developers with GitHub accounts to start working with PHP development.
In the end, the acceptance of patches will not change, but if patches are accepted the process will be less awkward than before, so I agree it is a good thing.
Stefan Jibrail Froelich - 2012-04-06 07:52:08 - In reply to message 2 from Manuel Lemos
I am aware of this. Git actually is the only versioning system I know and use.
What I am trying to say is, unless the Github repo is private, then there is not much sense in integrating with GH if the chances of accepting requests is low. If they want to encourage non core members to develop on php (as that seems to be the idea of putting it on Github), then they should be ready to accept more patches.
The whole idea of GH is "social" development.
That being said, if the team still refuses patches as much as they do now, then we should be prepared to see many forks of the php project on php by people tired of waiting for the core team to make up their minds and improve the language we all love so much.
And just maybe some new fork might become the defacto php. This would be very easy to do.
Imagine this, someone has some killer features to add to php, he forks it an adds these features that people need. Then his pull request is refused. Others see his fork and like it and start contributing to it. It becomes great, in the meanwhile, the core team adds some new features and bug fixes. He simply pulls these into his fork and resolves any conflicts (this is wicked easy with git). We now have a fork with active community participation that has more features than the main php repo. This was still possible earlier, but now it is so easy with git it is laughable.
All I want to say is thay, the core team needs to streamline their process of acceptance, and allow the community to improve upon php.
Manuel Lemos - 2012-04-13 06:19:54 - In reply to message 3 from Stefan Jibrail Froelich
Right, I agree with you that making it easier to fork increase the chances for forks to appear.
However, that is a bit utopic because PHP is a large project and unless you have time to dedicate to maintain it forever, you will hardly be able to maintain a fork.
PHP has been forked several times. Even recently we commented here about Robert Eisele PHP fork. You can think of Facebook HipHop PHP and Phallenger somewhat as forks too.
The question is, are you using those PHP forks? Why not?
In the end the vast majority will stick to the official PHP distribution even if that means dealing with a development that is very often closed to contributions of outside developers.