RE: [PEAR-DEV] Hosting PEAR's git repositories on git.php.net

Just my 2 cents on this topic...

I like GitHub. I'd like to keep using it as the reference repository.

However, I have no objections to using git.php.net as a redundant copy in case the unthinkable happens and the PEAR(2) GitHub repos are gone.

Since Git is a distributed VCS, a user could contribute to either repository and the changes can then be synced between git.php.net and GitHub. This in turn means either or both karma systems can be used to define who has rights over what. It's only a matter of developers choosing where they want to push changes, and QA giving them the karma there.

Assuming I get karma in both places, I accept having to manually do the syncs myself for the repos I control (it isn't that difficult... just one more remote to add alongside "origin"), though of course, I wouldn't mind an automation system that automatically checks GitHub for updates, and pulls stuff automatically. Or better yet, using GitHub's API to notify git.php.net whenever changes are pushed to GitHub, in which case git.php.net would automatically pull them (and would send me email if the pull fails for whatever reason, so that I could chime in and fix it).


For people who would prefer using git.php.net as the reference repository, again thanks to the fact Git is a distributed VCS, this shouldn't be too difficult to automate. Just make git.php.net force push changes to GitHub whenever it is being pushed to (I mean, Git does offer hooks for that, no?).

The combinations of these two ensures that git.php.net would always host a copy of the code, while also allowing GitHub to be used as a primary node. Worst case scenario is that GitHub deletes their copy for whatever reason (but keeps sending false update notices, which fail and start sending emails, until someone decides to disable GitHub syncs at git.php.net), and then, karma is redistributed at git.php.net, perhaps manually, perhaps based on package.xml credits, or perhaps by previously keeping the karmas in sync by allowing PEAR accounts to optionally specify a GitHub username that they'll be associated with (and for security's sake, the emails in both PEAR and GitHub would have to be the same, and confirmed at the email, at least at the time the association is made).

Regards,
Vasil Rangelov