X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FDeveloperPolicy.html;h=883509b4ffe354b35424579ee2b023a239ece10a;hb=e86ce7d94abaf7883a5d84dcb9a79c118b63672b;hp=e3e37f0bc1fc91b2f54ef075dd13d2cb57b177e6;hpb=8bb16ff2bbce53daf43693674ff2801e61458703;p=oota-llvm.git diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index e3e37f0bc1f..883509b4ffe 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -10,28 +10,28 @@
This policy is aimed at regular contributors to LLVM. People interested in +
This policy is aimed at frequent contributors to LLVM. People interested in contributing one-off patches can do so in an informal way by sending them to the llvm-commits mailing list and engaging another developer to see it through @@ -59,14 +59,15 @@ -
+This section contains policies that pertain generally to regular LLVM - developers. We always welcome random patches from - people who do not routinely contribute to LLVM, but expect more from regular - contributors to keep the system as efficient as possible for everyone. - Regular LLVM developers are expected to meet the following obligations in +
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.
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:
cvs diff -Ntdup -5- or with the utility utils/mkpatch. to make it easy to read the +
svn diff -x -u+ or with the utility utils/mkpatch, which makes it easy to read the diff.
When sending a patch to a mailing list, it is a good idea to send it as an + attachment to the message, not embedded into the text of the + message. This ensures that your mailer will not mangle the patch when it + sends it (e.g. by making whitespace changes or by wrapping lines).
@@ -132,22 +134,69 @@ reviewed after commit.Developers should participate in code reviews as both reviewers and + reviewees. If someone is kind enough to review your code, you should + return the favor for someone else. Note that anyone is welcome to review + and give feedback on a patch, but only people with Subversion write access + can approve it.
+ + + + + +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 + combination of code review plus post-commit review for trusted maintainers. + Having both is a great way for the project to take advantage of the fact + that most people do the right thing most of the time, and only commit + patches without pre-commit review when they are confident they are + right.
+ +The trick to this is that the project has to guarantee that all patches + that are committed are reviewed after they go in: you don't want everyone + to assume someone else will review it, allowing the patch to go unreviewed. + To solve this problem, we have a notion of an 'owner' for a piece of the + code. The sole responsibility of a code owner is to ensure that a commit + to their area of the code is appropriately reviewed, either by themself or + by someone else. The current code owners are:
+ +Note that code ownership is completely different than reviewers: anyone can + review a piece of code, and we welcome code review from anyone who is + interested. Code owners are the "last line of defense" to guarantee that + all patches that are committed are actually reviewed.
+ +Being a code owner is a somewhat unglamorous position, but it is incredibly + important for the ongoing success of the project. Because people get busy, + interests change, and unexpected things happen, code ownership is purely + opt-in, and anyone can choose to resign their "title" at any time. For now, + we do not have an official policy on how one gets elected to be a code + owner. +
+Developers are required to create test cases for any bugs fixed and any new - features added. The following policies apply:
+ features added. Some tips for getting your testcase approved:Note that llvm/test is 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.
Additionally, the committer is responsible for addressing any problems found in the future that the change is responsible for. For example:
We prefer for this to be handled before submission but understand that it's - not possible to test all of this for every submission. Our nightly testing +
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.
@@ -219,28 +272,55 @@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 the -LLVM oversight group.
+quality patches. If you would like commit access, please send an email to +Chris with the following information: + +Once you've been granted commit access, you should be able to check out an + LLVM tree with an SVN URL of "https://username@llvm.org/..." instead of the + normal anonymous URL of "http://llvm.org/...". The first time you commit + you'll have to type in your password. Note that you may get a warning from + SVN about an untrusted key, you can ignore this. To verify that your commit + access works, please do a test commit (e.g. change a comment or add a blank + line). Your first commit to a repository may require the autogenerated email + to be approved by a mailing list. This is normal, and will be done when + the mailing list owner has time.
If you have recently been granted commit access, these policies apply:
+In any case, your changes are still subject to code +review (either before or after they are committed, depending on the nature +of the change). You are encouraged to review other peoples' patches as well, +but you aren't required to.
@@ -249,31 +329,36 @@ quality patches. If you would like commit access, please send an email to theWhen 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 llvm-dev + the llvmdev email list, to the extent possible. The reason for this is to:
The design of LLVM is carefully controlled to ensure that all the pieces fit together well and are as consistent as possible. If you plan to make a - major change to the way LLVM works or - a major new extension, it is a good idea to get consensus with the development + major change to the way LLVM works or want to add a major new extension, it + is a good idea to get consensus with the development community before you start working on it.
+Once the design of the new feature is finalized, the work itself should be + done as a series of incremental changes, not as + a long-term development branch.
+Once the design of the new feature is finalized, the work itself should be - done as a series of incremental changes, not as a long-term development - branch. Long-term development branches have a number of drawbacks:
+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:
If you are interested in making a large change, and this scares you, please make sure to first discuss the change/gather - consensus then feel free to ask about the best way to go about making + consensus then ask about the best way to go about making the change.
We address here the issues of copyright and license for the LLVM project. - The object of the copyright and license is the LLVM source code and - documentation. +
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 University of - Illinois/NCSA Open Source License. + Illinois/NCSA Open Source License.
NOTE: This section deals with legal matters but does not provide - official legal advice. We are not lawyers, please seek legal counsel from an + legal advice. We are not lawyers, please seek legal counsel from an attorney.
Note that the LLVM Project does distribute some code that includes GPL - software (notably, llvm-gcc which is based on the GCC GPL source base). - This means that anything "linked" into to llvm-gcc must itself be compatible +
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 implies - that you any code linked into llvm-gcc and distributed may be subject to - the viral aspects of the GPL. This is not a problem for the main LLVM - distribution (which is already licensed under a more liberal license), but may - be a problem if you intend to do commercial development without redistributing - your source code.
+ that any code linked into llvm-gcc and distributed to others may be subject + to the viral aspects of the GPL (for example, a proprietary code generator + linked into llvm-gcc must be made available under the GPL). This is not a + problem for code already distributed under a more liberal license (like the + UIUC license), and does not affect code generated by llvm-gcc. It may be a + problem if you intend to base commercial development on llvm-gcc without + redistributing your source code.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.
+ + + +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 of the project by making it hard or impossible to reuse the code for + arbitrary purposes (including commercial use).
+ +When contributing code, we expect contributors to notify us of any potential + for patent-related trouble with their changes. If you own the rights to a + patent and would like to contribute code to LLVM that relies on it, we + require that you sign an agreement that allows any other user of LLVM to + freely use your patent. Please contact the oversight group for more + details.
+