This document contains the LLVM Developer Policy which defines the project's policy towards developers and their contributions. The intent of this policy is to eliminate miscommunication, rework, and confusion that might arise from the distributed nature of LLVM's development. By stating the policy in clear terms, we hope each developer can know ahead of time what to expect when - making LLVM contributions.

+ making LLVM contributions. This policy covers all llvm.org subprojects, + including Clang, LLDB, etc.

This policy is also designed to accomplish the following objectives:

@@ -63,60 +63,67 @@

Developer Policies

This section contains policies that pertain to frequent LLVM developers. We always welcome one-off patches from people who do not routinely contribute to LLVM, but we expect more from frequent contributors to keep the system as efficient as possible for everyone. Frequent LLVM contributors are expected to meet the following requirements in order for LLVM to maintain a high standard of quality.

Stay Informed

Developers should stay informed by reading at least the - llvmdev email - list. If you are doing anything more than just casual work on LLVM, it is - suggested that you also subscribe to the - llvm-commits - list and pay attention to changes being made by others.

Stay Informed

Developers should stay informed by reading at least the "dev" mailing list + for the projects you are interested in, such as + llvmdev for + LLVM, cfe-dev + for Clang, or lldb-dev + for LLDB. If you are doing anything more than just casual work on LLVM, it + is suggested that you also subscribe to the "commits" mailing list for the + subproject you're interested in, such as + llvm-commits, + cfe-commits, + or lldb-commits. + Reading the "commits" list and paying attention to changes being made by + others is a good way to see what other people are interested in and watching + the flow of the project as a whole.

We recommend that active developers register an email account with LLVM Bugzilla and preferably subscribe to the llvm-bugs - email list to keep track of bugs and enhancements occurring in LLVM.

+ email list to keep track of bugs and enhancements occurring in LLVM. We + really appreciate people who are proactive at catching incoming bugs in their + components and dealing with them promptly.

Making a Patch

When making a patch for review, the goal is to make it as easy for the reviewer to read it as possible. As such, we recommend that you:

Make your patch against the Subversion trunk, not a branch, and not an old - version of LLVM. This makes it easy to apply the patch.

Getting Started Guide

Similarly, patches should be submitted soon after they are generated. Old patches may not apply correctly if the underlying code changes between the time the patch was created and the time it is applied.
Patches should be made with this command: -
-
```
-svn diff -x -u
-
```
-
- or with the utility utils/mkpatch, which makes it easy to read - the diff.
Patches should be made with svn diff, or similar. If you use + a different tool, make sure it uses the diff -u format and + that it doesn't contain clutter which makes it hard to read.
Patches should not include differences in generated code such as the code - generated by autoconf or tblgen. The - utils/mkpatch utility takes care of this for you.
If you are modifying generated files, such as the top-level + configure script, please separate out those changes into + a separate patch from the rest of your changes.

When sending a patch to a mailing list, it is a good idea to send it as an @@ -134,8 +141,8 @@ svn diff -x -u

Code Reviews

LLVM has a code review policy. Code review is one way to increase the quality of software. We generally follow these policies:

@@ -166,8 +173,8 @@ svn diff -x -u

Code Owners

The LLVM Project relies on two features of its process to maintain rapid development in addition to the high quality of its source base: the @@ -185,14 +192,26 @@ svn diff -x -u else. The current code owners are:

Evan Cheng: Code generator and all targets.
Greg Clayton: LLDB.
Doug Gregor: Clang Frontend Libraries.
Howard Hinnant: libc++.
Anton Korobeynikov: Exception handling, debug information, and Windows codegen.
Duncan Sands: llvm-gcc 4.2.
Ted Kremenek: Clang Static Analyzer.
Evan Cheng: Code generator and all targets.
Chris Lattner: Everything not covered by someone else.
John McCall: Clang LLVM IR generation.
Chris Lattner: Everything else.
Jakob Olesen: Register allocators and TableGen.
Duncan Sands: dragonegg and llvm-gcc 4.2.

Note that code ownership is completely different than reviewers: anyone can @@ -209,8 +228,8 @@ svn diff -x -u

Test Cases

Developers are required to create test cases for any bugs fixed and any new features added. Some tips for getting your testcase approved:

@@ -233,16 +252,17 @@ svn diff -x -u them short. -

Note that llvm/test is designed for regression and small feature tests - only. More extensive test cases (e.g., entire applications, benchmarks, etc) +

Note that llvm/test and clang/test are designed for regression and small + feature tests only. More extensive test cases (e.g., entire applications, + benchmarks, etc) should be added to the llvm-test test suite. The llvm-test suite is for coverage (correctness, performance, etc) testing, not feature or regression testing.

Quality

The minimum quality standards that any change must satisfy before being committed to the main development branch are:

@@ -257,7 +277,7 @@ svn diff -x -u testcase so we know if the fix/feature ever regresses in the future. -

Code must pass the dejagnu (llvm/test) test suite.

Code must pass the llvm/test test suite.

The code must not cause regressions on a reasonable subset of llvm-test, where "reasonable" depends on the contributor's judgement and the scope of @@ -287,9 +307,12 @@ svn diff -x -u

We prefer for this to be handled before submission but understand that it - isn't possible to test all of this for every submission. Our nightly testing - infrastructure normally finds these problems. A good rule of thumb is to - check the nightly testers for regressions the day after your change.

+ isn't possible to test all of this for every submission. Our build bots and + nightly testing infrastructure normally finds these problems. A good rule of + thumb is to check the nightly testers for regressions the day after your + change. Build bots will directly email you if a group of commits that + included yours caused a failure. You are expected to check the build bot + messages to see if they are your fault and, if so, fix the breakage.

Commits that violate these quality standards (e.g. are very broken) may be reverted. This is necessary when the change blocks other developers from @@ -298,9 +321,8 @@ svn diff -x -u

- Obtaining Commit Access

Obtaining Commit Access

We grant commit access to contributors with a track record of submitting high quality patches. If you would like commit access, please send an email to @@ -361,8 +383,8 @@ svn diff -x -u

Making a Major Change

When a developer begins a major new project with the aim of contributing it back to LLVM, s/he should inform the community with an email to the llvmdev @@ -390,9 +412,8 @@ svn diff -x -u

Incremental Development -

Incremental Development

In the LLVM project, we do all significant changes as a series of incremental patches. We have a strong dislike for huge changes or long-term development branches. Long-term development branches have a number of drawbacks:

@@ -452,9 +473,8 @@ svn diff -x -u

Attribution of -Changes

Attribution of Changes

We believe in correct attribution of contributions to their contributors. However, we do not want the source code to be littered with random attributions "this code written by J. Random Hacker" (this is noisy and @@ -466,16 +486,19 @@ Changes

Overall, please do not add contributor names to the source code.

+ -

Copyright, License, and Patents -

+ -

This section addresses the issues of copyright, license and patents for the - LLVM project. Currently, the University of Illinois is the LLVM copyright - holder and the terms of its license to LLVM users and developers is the + LLVM project. The copyright holder for the code is held by the individual + contributors of the code and the terms of its license to LLVM users and + developers is the University of Illinois/NCSA Open Source License.

@@ -484,45 +507,44 @@ Changes

legal matters but does not provide legal advice. We are not lawyers, please seek legal counsel from an attorney.

For consistency and ease of management, the project requires the copyright - for all LLVM software to be held by a single copyright holder: the University - of Illinois (UIUC).

- -

Although UIUC may eventually reassign the copyright of the software to - another entity (e.g. a dedicated non-profit "LLVM Organization") the intent - for the project is to always have a single entity hold the copyrights to LLVM - at any given time.

- -

We believe that having a single copyright holder is in the best interests of - all developers and users as it greatly reduces the managerial burden for any - kind of administrative or technical decisions about LLVM. The goal of the - LLVM project is to always keep the code open and licensed - under a very liberal license.

Copyright

+ +

The LLVM project does not require copyright assignments, which means that the + copyright for the code in the project is held by its respective contributors + who have each agreed to release their contributed code under the terms of the + LLVM License.

+ +

An implication of this is that the LLVM license is unlikely to ever change: + changing it would require tracking down all the contributors to LLVM and + getting them to agree that a license change is acceptable for their + contribution. Since there are no plans to change the license, this is not a + cause for concern.

+ +

As a contributor to the project, this means that you (or your company) retain + ownership of the code you contribute, that it cannot be used in a way that + contradicts the license (which is a liberal BSD-style license), and that the + license for your contributions won't change without your approval in the + future.

License

We intend to keep LLVM perpetually open source and to use a liberal open - source license. The current license is the + source license. All of the code in LLVM is available under the University of - llinois/NCSA Open Source License, which boils down to this:

+ Illinois/NCSA Open Source License, which boils down to this:

You can freely distribute LLVM.
You must retain the copyright notice if you redistribute LLVM.
Binaries derived from LLVM must reproduce the copyright notice (e.g. in - an included readme file).
Binaries derived from LLVM must reproduce the copyright notice (e.g. in an + included readme file).
You can't use our names to promote your LLVM derived products.
There's no warranty on LLVM at all.

@@ -532,7 +554,22 @@ Changes

LLVM's license is not a "copyleft" license like the GPL). We suggest that you read the License if further clarification is needed.

- + +

In addition to the UIUC license, the runtime library components of LLVM + (compiler_rt and libc++) are also licensed under the MIT license, + which does not contain the binary redistribution clause. As a user of these + runtime libraries, it means that you can choose to use the code under either + license (and thus don't need the binary redistribution clause), and as a + contributor to the code that you agree that any contributions to these + libraries be licensed under both licenses. We feel that this is important + for runtime libraries, because they are implicitly linked into applications + and therefore should not subject those applications to the binary + redistribution clause. This also means that it is ok to move code from (e.g.) + libc++ to the LLVM core without concern, but that code cannot be moved from + the LLVM core to libc++ without the copyright owner's permission. +

Note that the LLVM Project does distribute llvm-gcc, which is GPL. This means that anything "linked" into llvm-gcc must itself be compatible with the GPL, and must be releasable under the terms of the GPL. This @@ -546,12 +583,12 @@ Changes

We have no plans to change the license of LLVM. If you have questions or comments about the license, please contact the - LLVM Oversight Group.

+ LLVM Developer's Mailing List.

Patents

To the best of our knowledge, LLVM does not infringe on any patents (we have actually removed code from LLVM in the past that was found to infringe). Having code in LLVM that infringes on patents would violate an important goal @@ -567,19 +604,6 @@ Changes

details.

- -

Developer Agreements

With regards to the LLVM copyright and licensing, developers agree to assign - their copyrights to UIUC for any contribution made so that the entire - software base can be managed by a single copyright holder. This implies that - any contributions can be licensed under the license that the project - uses.

- -

When contributing code, you also affirm that you are legally entitled to - grant this copyright, personally or on behalf of your employer. If the code - belongs to some other entity, please raise this issue with the oversight - group before the code is committed.

@@ -591,7 +615,7 @@ Changes

src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Written by the LLVM Oversight Group
- The LLVM Compiler Infrastructure
+ The LLVM Compiler Infrastructure
Last modified: $Date$