From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3049 invoked by alias); 14 May 2009 00:40:51 -0000 Received: (qmail 3032 invoked by uid 22791); 14 May 2009 00:40:50 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 May 2009 00:40:43 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n4E0efb9028408 for ; Wed, 13 May 2009 20:40:42 -0400 Received: from gateway.sf.frob.com (vpn-13-202.rdu.redhat.com [10.11.13.202]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4E0eetV014336 for ; Wed, 13 May 2009 20:40:41 -0400 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 36531357B; Wed, 13 May 2009 17:40:40 -0700 (PDT) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id E8339FC35D; Wed, 13 May 2009 17:40:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: GNU libc hacker Subject: git repository conventions Message-Id: <20090514004039.E8339FC35D@magilla.sf.frob.com> Date: Thu, 14 May 2009 00:40:00 -0000 Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00005.txt.bz2 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