Contents

Authenticated access

We provide authenticated access via the SSH protocol. This needs to
be sponsored by an existing maintainer (someone with "write after approval"
is not sufficient).

If you already have an account on sourceware.org/gcc.gnu.org, ask
overseers@gcc.gnu.org to add access to the GCC repository.
Include the name of your sponsor and CC: her.
If you do not have an account yet, use this form,
again specifying your sponsor.

We will then provision you on
gcc.gnu.org and inform you by mail. At this point,
check out a tree using the instructions below and add yourself
to the MAINTAINERS file. Note: Your first and last names must
be exactly the same between your account on gcc.gnu.org and the
MAINTAINERS file. Place your name in the correct section following
the conventions specified in the file (e.g. "Write After Approval"
is "last name alphabetical order").

Then produce a diff to that file and circulate it to the
gcc-patches list, whilst also checking in your change to
test write access (approval from the mailing list is not needed in this
one case). For all other changes, please be sure to follow the write
access policies below.

Setting up your local SVN tree

Once your account has been set up, check out the GCC sources by
issuing the command:

svn co svn+ssh://username@gcc.gnu.org/svn/gcc/trunk gcc

where username is your user name at gcc.gnu.org.

It is also possible to convert an existing SVN tree to use SSH by
using svn switch --relocate:

Write access policies

The GCC project grants developers various levels of write access to
and review authority over the GCC master sources. We have not put any
technical enforcement in place, rather we rely on everyone to follow
the appropriate policies.

Global reviewers.

A limited number of developers have global review permission
and can approve other people's changes to any part of the compiler.

Localized write permission.

This is for people who have primary responsibility for ports,
front ends, or other specific aspects of the compiler. These folks
are allowed to make changes to areas they maintain and related
documentation, web pages, and test cases (and target conditionals)
without approval from anyone else, and approve other people's changes
in those areas.
They must get approval for changes elsewhere in the compiler.

Maintainers of a port maintain the relevant files in
gcc/config, documentation, web pages, and test cases
and aspects of these relevant to that port. Port maintainers do
not have approval rights beyond this.

Localized review permission.

This is similar to localized write permission, except
that reviewers required approval for their own changes.

Write after approval.

This is folks that make regular contributions, but do not
fall into one of the previous categories. People with write
after approval need to submit their patches to the list; once the
patches have been approved by the appropriate maintainers the
patches may be checked in. The steering committee
or a well-established GCC maintainer (including reviewers) can
approve for write access any person
with GNU copyright assignment papers in place and known to submit
good patches.

The list of folks with write access to the repository can be found
in the MAINTAINERS file in the GCC distribution.

When you have checked in a patch exactly as it has been approved,
you do not need to tell that to people -- including the approver.
People interested in when a particular patch is committed can check
SVN or the gcc-cvs
list.

Free for all

The following changes can be made by everyone with SVN write access:

Obvious fixes can be committed without prior approval. Just check
in the fix and copy it to gcc-patches. A good test to
determine whether a fix is obvious: will the person who objects to
my work the most be able to find a fault with my fix? If the fix
is later found to be faulty, it can always be rolled back. We don't
want to get overly restrictive about checkin policies.

Similarly, no outside approval is needed to revert a patch that you
checked in.

Creating and using a branch for development,
including outside the parts of the compiler one maintains, provided that
changes on the branch have copyright assignments on file. Merging such
developments back to the mainline still needs approval in the usual way.

Testing changes

All changes must be tested according to the
instructions for testing patches
before they are checked in. If you wrote the patch yourself, you
should test it yourself, unless there is a reason why someone else
must do it for you (for instance, if you are fixing a problem on a
system you do not have access to). If you are checking in a patch for
someone else, you only need to test it if they did not.

You must test exactly the change you intend to check in; it is not
good enough to have tested an earlier variant. (Unless the only
changes from the earlier variant are formatting and comment changes;
if there are any changes to the code itself you
should re-bootstrap.) It is a good idea to re-test patches which were
submitted a long time ago before applying them, even if nothing
appears to have changed.

When you post your change to gcc-patches, state the
canonical name(s) of the platform(s) you used for testing.

These rules are designed to ensure that checked-in code does not
contain bugs that prevent other people from continuing to get their
work done. There will always be bugs, but these rules help to
minimize the amount of time where the tree does not build at
all. Repeated failure to adhere to these rules could result in the
revocation of check-in privileges by the Steering Committee.

Checking in a change

The following is meant to provide a very quick overview of how to
check in a change. It is not meant to be a replacement for the SVN
manual but instead a supplement. The SVN manual is available both
as part of the SVN source distribution, as well as at the book
Version Control with
Subversion.

In all the commands listed below, you can give an explicit list of
filenames to the SVN command. We recommend you list files explicitly
when performing checkins to avoid accidental checkins of local
code.

We prefer that each SVN checkin be of a complete, single logical
change, which may affect multiple files. The log message for that
checkin should be the complete ChangeLog entry for the change. This
makes it easier to correlate changes across files, and minimizes the
time the repository is inconsistent. If you have several unrelated
changes, you should check them in with separate SVN commit
commands.

Sync your sources with the master repository via "svn
update" before attempting a checkin; this will save you a little
time if someone else has modified that file since the last time you
synced your sources. It will also identify any files in your local
tree that you have modified.

Apply the patch to your local tree and update the ChangeLog file.
Use the current date/time for the ChangeLog entry, not the time that
the patch was submitted.

Make sure to rebuild any generated files that would be affected by
the patch. Make sure to check them in along with the files explicitly
modified by the patch.

We recommend using "svn diff" after applying a patch to a
local tree. Review the output to make sure that only the changes you
wanted to check in will be checked in. Also check to see if the
copyright dates need to be updated.

Use "svn commit" to check in the patch. You can enter
the log message via the "-m" argument to commit, or wait for
the editor window to appear and enter the log message in the editor
window.

After exiting the editor, SVN will connect to the GCC SVN server
and check in your changes. When your prompt returns the checkin is
finished. A message will be sent to the gcc-cvs mailing
list indicating that a change was made. SVN will provide a message if
an error occurs and it will not check in any files.

Example check-in session

Here's an actual check-in session for a patch John Carr recently
sent to the GCC list. This was the ChangeLog for his change:

The question marks indicate files in my local repository that are
not part of the official sources. The "M" indicates files I've
changed locally for some unrelated work -- thus I have to be careful
to avoid checking them in. A "U" would have indicated a file that SVN
updated because my local copy was out of date relative to the master
sources.

When merging changes from mainline (or another branch) to a branch,
do not copy the entire set of ChangeLog entries. Just use something
like "Merge from mainline" or similar.

Tips&Tricks around your account

Your gcc.gnu.org account also receives e-mail (and is what you
use for Bugzilla). If you ever need to change the address e-mail to
username@gcc.gnu.org is forwarded to, you can easily
do so using

ssh username@gcc.gnu.org email mynewaddress@example.com

Similarly if you want to add a new SSH key to your account:

ssh username@gcc.gnu.org appendkey < KEYFILE

Or replace all your SSH keys:

ssh username@gcc.gnu.org replacekey < KEYFILE

For questions related to the use of GCC,
please consult these web pages and the
GCC manuals. If that fails,
the gcc-help@gcc.gnu.org
mailing list might help.
Comments on these web pages and the development of GCC are welcome on our
developer list at gcc@gcc.gnu.org.
All of our lists
have public archives.

Copyright (C)
Free Software Foundation, Inc.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.