This is the mail archive of the
mailing list for the glibc project.
Re: project branches in the glibc git repository
- From: Roland McGrath <roland at redhat dot com>
- To: Ben Elliston <bje at au1 dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 17 Jun 2009 23:04:56 -0700 (PDT)
- Subject: Re: project branches in the glibc git repository
- References: <1245284795.25105.5.camel@helios>
Conventions for branches come in two tiers. The top tier conventions for
the whole repository are the copyright requirements, and assignment of each
"<category>/*" branch name space to an individual who gets to specify the
second-tier conventions for <category>.
The overall community here only has to agree on the top-tier conventions.
The current branch name conventions are:
name space who sets detailed policies (by sw username)
master drepper, roland
release/* release managers (separate discussion)
<username>/* <username> (do as you will)
fedora/* jakub, roland, schwab
(A good community citizen would enshrine all this on the glibc wiki.)
The generic policy for adding a <notausername>/* item to that list is to
propose it on libc-alpha or libc-hacker and if nobody calls you rude
names, then consider it done (and then you should update the mythical
wiki page to reflect the set of name spaces and their owners).
If you'd like to add:
that's fine by me. To fulfull your "update the wiki" step of the
policy, you first get to create the wiki page, just your luck.
(GlibcGit might be the one to change, or kibitz here about wiki organization.)
The policies for ibm/* branches are then up to you. (Or name a
different person or set to be called authoritative for ibm/*.) I might
have some suggestions, but it's your playpen. Note that while each
designee in the list is free to set some branches in their space to
whomever they like as policy, all people authorized to push will need
sourceware accounts in the glibc group. Adding each person to the group
goes through the normal overseers process, with explicit approval from
me or another glibc maintainer. We'll just expect a vouching for sanity
and competence, that the person both really truly understands FSF
copyright protocols and always carefully respects per-branch policies on
what they are allowed to touch and how.