The very beginning already talks about how to git clone the repo. The
section about checking out specific versions doesn't really belong in
GettingStarted and seems unnecessary.
I've not tried to change the purpose or style of the doc, just edited
for clarity and removed any Phabricator related language in favour of
GitHub terms.
Where possible, I've swapped direct links to LLVM's website with RST
links to the local documents. Which should be a bit more resilient.
Also it's less confusing if you're editing multiple pages locally, you
don't accidentally end up on the live site.
This adds first version of a GitHub workflow in the documentation and marks some
sections as deprecated. We should clean up these sections ASAP. I was
just keen to get something on the documentation site as soon as
possible.
This addresses further post-review feedback
(https://reviews.llvm.org/D155081) with commit
677326999f270395ecaec026178fe7ed148a0068 by rearranging some of the
text into separate bullets and adding a clarifying statement.
677326999f270395ecaec026178fe7ed148a0068 changed the developer policy
but dropped a documentation link telling folks to add a link to the
Phabricator page where review occurred. This restores that link and
wording, thanks to post-review feedback for catching the regression.
This specifies the developer policy on adding links in source & test
files and commit messages, related to discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847
The intent is to discourage adding links to resources that are not
available to the community as a whole (dead links, links to internal
documentation, links to internal bug trackers, etc) from source and
test files, while still allowing such links to appear in other contexts
as needed. It suggests to instead add sufficient context in the
surrounding comments to make such links unnecessary.
It also clarifies that these links can appear in commit messages as
metadata (similar to how we already have Differential Revision and
Fixes metadata with links).
Differential Revision: https://reviews.llvm.org/D155081
We've recently had issues appropriately notifying users and
stakeholders of changes to projects that may be potentially disruptive
when upgrading. This led to discussion on Discourse about how to
improve the situation, which can be found at:
https://discourse.llvm.org/t/rfc-add-new-discourse-channel-for-potentially-breaking-disruptive-changes-for-clang/65251
Ultimately, it sounds like we want to encourage three things:
* Alert vendors during the code review so they can provide early
feedback on potentially breaking changes that would be unacceptable
for them.
* Alert vendors and users after committing the changes so they can
perform pre-release testing on a completed change to determine if it
causes unreasonable problems for them.
* Alert users more clearly through the release notes so that it's
easier to determine how disruptive an upgrade might be.
This updates the developer policy accordingly.
Differential Revision: https://reviews.llvm.org/D134878
We are already using the Co-author-by git tag, but don't have documentation in
our developer policy about it. Fix that.
Differential Revision: https://reviews.llvm.org/D134740
Specifically:
- Diffs are not passed around on mailing lists any more.
- Diffs should be `-U999999`.
- Clarify part about automated emails.
Differential review: https://reviews.llvm.org/D128645
In some case, GitHub will not send notification for commit access invitation. Add invitation link for people don't get notification from GitHub.
Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D124191
Plenty of new targets nowadays and I found myself repeating the same
thing over and over, so this is more or less what we said over the last
few years, but condensed in an ordered fashion and easy to digest.
This does not change any of the recommendations, only documents what we
have been saying for years.
This has come up a few times recently, and I was surprised to notice that we don't have anything in the docs.
This patch deliberately sticks to stuff that is uncontroversial in the community. Everything herein is thought to be widely agreed to by a large majority of the community. A few things were noted and removed in review which failed this standard, if you spot anything else, please point it out.
Differential Revision: https://reviews.llvm.org/D99305
Before, the first mention of LLVM's license on the developer policy page stated
that LLVM's license is Apache 2. This patch makes that more accurate by
mentioning the LLVM exception this first time the LLVM license is discussed on
that page, i.e. Apache-2.0 with LLVM-exception.
Technically, the correct SPDX identifier for LLVM's license is 'Apache-2.0 WITH
LLVM-exception', but I thought that writing the 'WITH' in lower case made the
paragraph easier to read without reducing clarity.
Differential Revision: https://reviews.llvm.org/D96482
Adding new paragraphs under "Introducing New Components" section to
check the different levels of support we have, to help introduction of
smaller set of changes without overwhelming new collaborators and
potentially losing the contribution.
Differential Revision: D91013
Summary:
Fixes two minor issues in the docs present under `ninja docs-llvm-html`:
1 - A header is too small:
```
Warning, treated as error:
llvm/llvm/docs/Passes.rst:70:Title underline too short.
``-basic-aa``: Basic Alias Analysis (stateless AA impl)
------------------------------------------------------
```
2 - Multiple definitions on a non-anonymous target (llvm-dev mailing list):
```
Warning, treated as error:
llvm/llvm/docs/DeveloperPolicy.rst:3:Duplicate explicit target name: "llvm-dev mailing list".
```
Reviewers: lattner
Reviewed By: lattner
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83416
Uploading output from `git format-patch` fails when version has
more than 2 dots, e.g. git version 2.24.1.windows.2 which is
currently recommended by e.g. GitExtensions or 2.24.1.rc on Linux.
Differential Revision: https://reviews.llvm.org/D72374
This is an update to the documentation of our community code-review process.
Based on the RFC: High-Level Code-Review Documentation Update
(http://lists.llvm.org/pipermail/llvm-dev/2019-November/136808.html).
In this patch, I've pulled out the documentation into a separate file, and
broken it into a number of subsections. This is, of course, just one further
step in better documenting our community processes. I expect we'll continue to
improve this over time. Thank you to everyone who provided feedback!
Differential Revision: https://reviews.llvm.org/D71916
Experimental targets are meant to be maintained by the community behind
the target. They are not monitored by the primary build bots. This
change clarifies that it is this communities responsibility for things
like test fixes related to the target caused by changes unrelated to
that target.
See http://lists.llvm.org/pipermail/llvm-dev/2020-February/139115.html
for a full discussion.
Reviewed by: rupprecht, lattner, MaskRay
Differential Revision: https://reviews.llvm.org/D74538
Summary:
The older method of adding 'Patch by John Doe' is documented in the
`Attribution of Changes` section to support correct attribution of commits
that pre-date the adoption of git.
Reviewers: hfinkel, aaron.ballman, mehdi_amini
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72468
Summary:
Capture the current agreed-upon toolchain update policy based on the following
discussions:
- LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"
llvm.org/devmtg/2018-10/talk-abstracts.html#bof3
- A Short Policy Proposal Regarding Host Compilers
lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html
- Using C++14 code in LLVM (2018)
lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html
- Using C++14 code in LLVM (2017)
lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html
- Using C++14 code in LLVM (2016)
lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html
- Document and Enforce new Host Compiler Policy
llvm.org/D47073
- Require GCC 5.1 and LLVM 3.5 at a minimum
llvm.org/D46723
Subscribers: jkorous, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D56819
llvm-svn: 351765
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
official Git repository.
Remove the directions for using git-svn, and demote the prominence of
the svn instructions.
Also, fix a few other issues while I'm in there:
* Mention LLVM_ENABLE_PROJECTS more.
* Getting started doesn't need to mention test-suite, but should
mention clang and the other projects.
* Remove mentions of "configure", since that's long gone.
I've also adjusted a few other mentions of svn to point to github, but
have not done so comprehensively.
Differential Revision: https://reviews.llvm.org/D56654
llvm-svn: 351130
