GitHub (and Bitbucket) have made forking a social endeavour - it's meant
to be a noisy space of code forks for collaboration just as Stas mentioned.
Bottom line: *if* a DVCS is adopted - enhancing policies and a process
that supports little additional burden on maintainers is required.
Having those in place would seem to address the most prudent fear in
this conversation.
Just because somebody uses DVCS / Github / Bitbucket; doesn't entitle
them to anything more than before. It's just another means to
collaborate in a more rapid manner; with updated tooling.
On 8/12/2011 2:02 PM, Stas Malyshev wrote:
Hi!
On 8/12/11 11:47 AM, Lester Caine wrote:
Pull requests, for one.
Push/Pull from local copy?
No, no. Pull requests and push/pull are very different things. Having
people just push whatever they like whenever they like into main code is
what we have now, and it's not really the best way to work on a big
project. Please see on github how pull requests are implemented.
The TEAM has a master copy on github or better still git.php.net, but
you don't
need 10000 other copies on github as well? I don't like the code
Drupal produce,
It's not copies. And yes, I need them - because not every change should
immediately go into master repo. Much better way is to publish it in
your local repo and have it reviewed and then merged into master repo.
Or not. Or merged later. github allows to manage this process better
than storing assorted patches in emails and bugs and pastebin, etc.
Sandboxes and development branches are the right way to go, but could
actually
Branches are different things than github forks, for different purposes.
Branch is a project, fork is a workspace. You can have multiple people
work on a project, using multiple workspaces.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
