The following text was sent to me by Kevin Mihelich @ Arch Linux ARM, with permission to post it here as well: We poll the svntogit repo regularly to bring up updates to packages that are made by Arch maintainers, and build everything as-is. For packages that require modifications (configure settings, patches, etc.) to build on ARM systems, we take the package and put it into our github repo in the same spot under core/extra/community with the needed changes. Our build system software then recognizes that the same package is in github and svntogit under the same repo, and uses the github version over svntogit. We also maintain two separate repos out of our github, one called 'alarm' for packages we create, and an 'aur' repo for some of the highly requested AUR packages (since many ARM systems lack the ability to build packages in timely manner, or at all). Like has been mentioned, github's ability to clone and submit pull requests has been a huge feature for us, as it allows contributions and fixes to packages from people that don't want to be a maintainer. It allows us to quickly review the changes, and if everything is fine it get merged and built automatically by the build system -- a huge time saver for us. Additionally, you can dig into commits or existing files and comment on particular lines, creating separate conversation threads on points of issue that need to be resolved. Now, if I may, here's how your decisions on how you set up a git repo in place of svn affect us. Right now, with the svntogit providing a merged repo of all the packages in two places (core/extra in one, community in another) allows me to simply poll the two git repos for changes and operate on that changeset. This means that when packages get added, removed, or modified, I'm able to see everything that takes place. If each package was to be split into its own git repo, I would need to devise some (potentially ugly) solution to scrape all of the current repos from somewhere, match them against what I know to exist, add packages (repos) that just got created and delete packages (repos) that just got removed, then further correlate which pacman repo each belongs to, if repos have changed, etc. It would also require that I either find some way to determine which package git repos changed and only poll them, or potentially have to poll the ~4500 git repos that would exist individually. In short, I don't know how I would accomplish this off the top of my head, and it could be a massive pain to implement. My two cents toward the repo structuring would be to follow the same structure that is in place now with svntogit: have a packages.git that contains core and extra, which Arch developers have access to change, and a community.git that contains community, which devs and TUs have access to change. Unless there is some overbearing need to individually delegate write access per package, individual git repos per package seems like it would be more of an administrative headache than it is worth (aside from destroying my current development model for Arch Linux ARM). Should you decide to use a service like github, a combined package repo also means that community-generated pull requests are also combined, allowing more people to be notified of changes, submit their input, or merge changes when someone is on vacation. A combined repo also means that you can delegate a 'testing' branch to contain all the testing versions of all the packages, allowing one to push/pull to all of the testing packages in one move, or merge a large set of changes back to stable, without having to go through and do the same operation on multiple git repos (I'm specifically thinking of things like the Gnome and KDE package sets). One could potentially create a 'gnome-testing' branch, do all the changes and builds based on that branch, then when it's ready merge that branch back into stable and you're done.