git repository conventions

[Roland McGrath <roland at redhat dot com>]

The final format conversion is still being hashed out and we do not yet
have a git repository that receives any git commits.  But it's time now to
start working out the conventions for using the git repository in the future.

Once the git repository is ready technically, we'll start with the only
real status quo convention we have: the only active branch is 'master', and
the only pushes to it will by those who did CVS trunk commits in the old
practice.  The new rules for future practice will be hashed out by our
discussion here, nothing much is decided yet.

The historical branches and tags from CVS have their CVS names prefixed
with 'cvs/' in the git repository.  After the final format conversion,
these will stick around forever as history, but never be changed again.
If any of those old branches get used in the future, we'll start that by
copying the cvs/branch tip's commit id to a new branch name based on the
new conventions we work out.  We'll make back-dated, signed git tags for
all the past released versions.

Here are my proposals for naming and access conventions for future work.
Commence debate.

The cardinal rule of the glibc repository is that all commits must be
covered by proper copyright assignment paperwork already on file with the
FSF.  If you cannot attest that the changes' authors have all their
paperwork in order, then do not make the commit.  Do not pull/merge someone
else's git tree unless you are sure they are following these rules.
Someone who says they intend to submit paperwork does not count.  If the
paperwork is not in and verified already, don't use the code.  If you have
done any pulls/merges from other people, you are responsible for being
absolutely sure all the commit history you pulled in was properly covered
before you do any git push or ask another libc maintainer to do a pull from
your outside server.  These rules apply to the entire glibc repository, all
branches, including any private branches, and including all commit history,
everything that is in the sourceware glibc.git in any way, shape, or form.
This is the one rule that is nonnegotiable and is not open for debate.  If
you don't like it, don't ever expect to push to this repository or have one
of its maintainers pull from yours.

First point: private branches and tags.  Everyone with repository write
access is free to have private branches and tags, subject to the cardinal
rule about copyright status.  The branch names 'yourname/*' and the tag
names 'yourname/*' are free to use however you like, where 'yourname' is
your username on sourceware.  We expect some sensible discretion in not
using our repository for things that don't make a lot of sense.  We expect
folks to clean out their old private branches (e.g. delete a useless old
one with "git push origin :roland/foobar") when they are no longer useful.
(We will eventually do some "git gc" operations on the repository, so the
old history of removed branches will be unrecoverably lost if you don't
save them yourself.)  Don't make a lot of stupid private branch names that
just track another branch, because they all show up in gitweb.

GIT makes it easy to fork a repository from the glibc one and publish your
own entwined repository with your own branches on your own servers.  People
without permissions on sourceware can do this and have libc maintainers
pull from their trees.  Private branches in the canonical glibc repository
on sourceware are provided to make it easier for the whole glibc community
to notice and follow your work, or if it's a pain to publish elsewhere.

Second point: "official" tags.  The only purpose I see off hand for
top-level tag names is for our official releases.  These will have names
like "glibc-2.10.1", and be signed tags (git tag -s).  As I mentioned,
we'll retroactively make back-dated tags like this for all the old official
release versions.

Third point: shared community/distro branches and tags.  Like each user's
private branches and tags, there can be 'prefix/*' branches and tags shared
by those working on the 'prefix' project.  These prefixes will be approved
by consensus here, and the active set documented on the wiki.  The only one
we already know will be actively used is 'fedora/*'; Jakub owns that name
space, though I expect to work out some specific conventions with him.

Last point: release branches.  There has not been any actual procedure for
release branches operating in recent memory.  Perhaps we'll get it together
for a real one of these days.  If we had one, then the naming convention I'd
think we want is this: 'release/x.y/*' prefix, with the "main" release
branch being 'release/x.y/master', e.g. 'release/2.10/master'.  This leaves
the way open for 'release/x.y/blahblah' branches, which will likely be
useful for collaborative work on stable branch releases (if that ever happens).

The nature of GIT makes it easy to add, change, and rename branches later.
The branches and their names are not really part of the commit history.
So, aside from signed tags, this is a bit more fungible in the future than
were CVS conventions.  Nonetheless, I think we should give a little though
to agreeing to GIT naming conventions that will serve us in the future.


Thanks,
Roland