Hi, So I moved the github repo of wxPerl to the organization 'wxPerl' I created on github some time ago (to be sure the name wouldn't get taken by somebody who wouldn't want to transfer/share it). Now I can add whoever you guys think should be made as an owner of the repo.
The new repo link is : https://github.com/wxPerl/wxPerl For the case someone feels uncomfortable to ask me: I have no objection to remove myself from the owners if requested. My purpose is to help the wxPerl project to reach for more peoples contributions. I'm convinced git (and github) is an efficient tool for this. So I ported the svn repo and keep it in sync with the _main_ repository on svn. A script runs every 2 hours to mirror new commits on svn to the github repo. As of today, the svn repo is still to be considered the _only_ official repository. This github mirror is nothing more than an unofficial mirror. I understand this repo @ github can be misunderstood as being the official repo. On request (by current maintainers) I will promptly remove it. I've pushed it there because: no-one disagreed with the previous location @ ecocode on github, and because this can be a good way for current maintainers to play with github, without having to do the porting and owners stuff. It's nothing difficult, but at least this has been done and won't keep them from doing 'important' work ;) As I imagine from Steve's post, some explanations can be handy to help considering an official move to git(hub): There are 3 major possibilities to contribute to a github project: - as an owner or contributor, you commit locally and push your commits to the main repo when you're ok with it. - as a github user without permissions, you use pull-requests which are then easy to merge by an owner or contributor. (Having a github user account is free) - as a non-github user, you send patches by mail. They are a little more cumbersome to apply, but that's similar to svn patches I guess. If you are not familiar with git workflows and cheap branching strategies, take a look at this blog post which introduces a very neat workflow configuration. It is used as a guide for lots of projects using git: http://nvie.com/posts/a-successful-git-branching-model/ best -- erik colson
