X.Org currently keeps the source for its stuff in a GIT repository. This page is one of several documents describing that repository. Note: The xserver module follows a slightly different development model than outlined below. Some information below may not apply. Please read the XServer page for more detail.
Who can access the repository?
Anyone. See the users' GIT page for instructions about how to access the repository anonymously.
Who can get repository commit privileges?
Anyone can apply for commit 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 commit 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 commit privileges. One-time-fix submissions should be done to the xorg-devel mailing list, or to the freedesktop.org Bugzilla, against the xorg product.
Is there something in between?
- 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. You might host this repository on your own website, on a hosting site such as gitorious, or you might request an account at people.freedesktop.org. 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 initially do development this way.
ChangeLog
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.
Master Repository Commit Rules
- Before being given commit priviliges on the master repository, you need to read and agree to the commit rules described in this section.
Who may commit what?
- Committers are allowed to commit 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.
Use proper discretion
- 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. Again, please note the different rules for the X server.
What should you do after the commit?
Committers are responsible for their own commits. They should be prepared to fix without delay problems their commit may create, or revert their changes. Ideally a committer would watch the tinderbox to see if their changes caused any build breakages afterwards, though we currently need more machines in the tinderbox for it to be useful.
What if you screw up the repo?
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.