RepoPolicy

X.Org currently keeps the source for its stuff in a GIT repository. This page is one of several documents describing that repository.

Who can access the repository?

Anyone. See the users' GIT page for instructions about how to access the repository anonymously.

All submissions should be done as merge requests to the appropriate repo under https://gitlab.freedesktop.org/xorg. We normally expect to see a history of successful merge requests before considering to give privileges to merge into those repos.
Anyone can apply for merge privileges to the master repository. You should give a description of what you plan to do, or even better provide an initial set of patches you plan to apply. A sponsor from the current X.Org team is required before merge privileges can be granted. This sponsor needs to have some idea of your background and experience. You may be asked for a sample of code to judge the quality of your coding. Only people with serious projects and long term commitment get merge privileges.

Thanks to GIT, yes, there is. GIT makes it quite straightforward for you to maintain your own repository of changes that tracks our master repository. If you plan to request merging changes from your repository into our repos, you can fork our repo into your personal namespace on gitlab.freedesktop.org. See https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home for instructions on the necessary privileges to do this. This makes it easy for folks with commit access to the master repository to incorporate your changes, and gives you a chance to establish a track record as a developer in a "safe" environment. We highly recommend that you do development this way.

X.Org no longer uses manually maintained ChangeLog files, but instead uses dist-hook entries in the top-level Makefile to generate ChangeLog from git log output when tarballs are being generated.

Before being given merge privileges on the master repository, you need to read and agree to the commit rules described in this section.

Committers are allowed to merge to master (where ongoing development takes place) only after review. Exceptions are obvious bug and typo fixes. Write access to other branches is controlled by the branch owner. The release manager is the owner of the release branch.

The general rule is (especially when committing to HEAD): only commit stuff you are certain about. If you don't understand a particular area and you think you need to commit a patch: ASK! There may be someone who can help you. In general, it's nice to post to the appropriate list describing the changes you've just made or would like to make. That increases the visibility of the change (potentially saving others lots of time) and gives others a chance to comment on and/or improve upon your modifications. Don't worry if you don't get any comments: it may be that your patch is perfect, so go ahead and check it in. If there's something wrong with it, you'll find out soon enough.

Committers are responsible for their own commits. They should be prepared to fix without delay problems their commit may create, or revert their changes.

Please email sitewranglers@freedesktop.org promptly if you feel you may have corrupted the master GIT repository. This is not something you are likely to be able to fix yourself, and we'll need to tackle it as soon as possible. (The good news is that with GIT this is very difficult to do.) If you are unhappy with a patch sequence, and think the repo needs a rollback or rebase, please contact someone as soon as possible. These things are much easier the sooner they're tackled. In general, we will not disturb commits to the repository without a very good reason, so please be careful out there. People's commit privileges shall be revoked if they repeatedly violate these rules.