[arch-dev-public] Git

[Alexander Rødseth]

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.