mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 10:42:39 +01:00
[docs] Make ReleaseProcess.rst 80 column. NFCI
llvm-svn: 322849
This commit is contained in:
Joel Jones
parent
f2d53ff2dd
commit
df1734c950
@ -9,9 +9,9 @@ How To Validate a New Release
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document contains information about testing the release candidates that will
|
||||
ultimately be the next LLVM release. For more information on how to manage the
|
||||
actual release, please refer to :doc:`HowToReleaseLLVM`.
|
||||
This document contains information about testing the release candidates that
|
||||
will ultimately be the next LLVM release. For more information on how to
|
||||
manage the actual release, please refer to :doc:`HowToReleaseLLVM`.
|
||||
|
||||
Overview of the Release Process
|
||||
-------------------------------
|
||||
@ -21,26 +21,28 @@ and it'll be the role of each volunteer to:
|
||||
|
||||
* Test and benchmark the previous release
|
||||
|
||||
* Test and benchmark each release candidate, comparing to the previous release and candidates
|
||||
* Test and benchmark each release candidate, comparing to the previous release
|
||||
and candidates
|
||||
|
||||
* Identify, reduce and report every regression found during tests and benchmarks
|
||||
|
||||
* Make sure the critical bugs get fixed and merged to the next release candidate
|
||||
|
||||
Not all bugs or regressions are show-stoppers and it's a bit of a grey area what
|
||||
should be fixed before the next candidate and what can wait until the next release.
|
||||
should be fixed before the next candidate and what can wait until the next
|
||||
release.
|
||||
|
||||
It'll depend on:
|
||||
|
||||
* The severity of the bug, how many people it affects and if it's a regression or a
|
||||
known bug. Known bugs are "unsupported features" and some bugs can be disabled if
|
||||
they have been implemented recently.
|
||||
* The severity of the bug, how many people it affects and if it's a regression
|
||||
or a known bug. Known bugs are "unsupported features" and some bugs can be
|
||||
disabled if they have been implemented recently.
|
||||
|
||||
* The stage in the release. Less critical bugs should be considered to be fixed between
|
||||
RC1 and RC2, but not so much at the end of it.
|
||||
* The stage in the release. Less critical bugs should be considered to be
|
||||
fixed between RC1 and RC2, but not so much at the end of it.
|
||||
|
||||
* If it's a correctness or a performance regression. Performance regression tends to be
|
||||
taken more lightly than correctness.
|
||||
* If it's a correctness or a performance regression. Performance regression
|
||||
tends to be taken more lightly than correctness.
|
||||
|
||||
.. _scripts:
|
||||
|
||||
@ -52,10 +54,12 @@ The scripts are in the ``utils/release`` directory.
|
||||
test-release.sh
|
||||
---------------
|
||||
|
||||
This script will check-out, configure and compile LLVM+Clang (+ most add-ons, like ``compiler-rt``,
|
||||
``libcxx``, ``libomp`` and ``clang-extra-tools``) in three stages, and will test the final stage.
|
||||
It'll have installed the final binaries on the Phase3/Releasei(+Asserts) directory, and
|
||||
that's the one you should use for the test-suite and other external tests.
|
||||
This script will check-out, configure and compile LLVM+Clang (+ most add-ons,
|
||||
like ``compiler-rt``, ``libcxx``, ``libomp`` and ``clang-extra-tools``) in
|
||||
three stages, and will test the final stage.
|
||||
It'll have installed the final binaries on the Phase3/Releasei(+Asserts)
|
||||
directory, and that's the one you should use for the test-suite and other
|
||||
external tests.
|
||||
|
||||
To run the script on a specific release candidate run::
|
||||
|
||||
@ -66,25 +70,32 @@ To run the script on a specific release candidate run::
|
||||
-test-asserts \
|
||||
-no-compare-files
|
||||
|
||||
Each system will require different options. For instance, x86_64 will obviously not need
|
||||
``-no-64bit`` while 32-bit systems will, or the script will fail.
|
||||
Each system will require different options. For instance, x86_64 will
|
||||
obviously not need ``-no-64bit`` while 32-bit systems will, or the script will
|
||||
fail.
|
||||
|
||||
The important flags to get right are:
|
||||
|
||||
* On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2, change it to ``-rc 2`` and so on.
|
||||
* On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2,
|
||||
change it to ``-rc 2`` and so on.
|
||||
|
||||
* On non-release testing, you can use ``-final`` in conjunction with ``-no-checkout``, but you'll have to
|
||||
create the ``final`` directory by hand and link the correct source dir to ``final/llvm.src``.
|
||||
* On non-release testing, you can use ``-final`` in conjunction with
|
||||
``-no-checkout``, but you'll have to create the ``final`` directory by hand
|
||||
and link the correct source dir to ``final/llvm.src``.
|
||||
|
||||
* For release candidates, you need ``-test-asserts``, or it won't create a "Release+Asserts" directory,
|
||||
which is needed for release testing and benchmarking. This will take twice as long.
|
||||
* For release candidates, you need ``-test-asserts``, or it won't create a
|
||||
"Release+Asserts" directory, which is needed for release testing and
|
||||
benchmarking. This will take twice as long.
|
||||
|
||||
* On the final candidate you just need Release builds, and that's the binary directory you'll have to pack.
|
||||
* On the final candidate you just need Release builds, and that's the binary
|
||||
directory you'll have to pack.
|
||||
|
||||
This script builds three phases of Clang+LLVM twice each (Release and Release+Asserts), so use
|
||||
screen or nohup to avoid headaches, since it'll take a long time.
|
||||
This script builds three phases of Clang+LLVM twice each (Release and
|
||||
Release+Asserts), so use screen or nohup to avoid headaches, since it'll take
|
||||
a long time.
|
||||
|
||||
Use the ``--help`` option to see all the options and chose it according to your needs.
|
||||
Use the ``--help`` option to see all the options and chose it according to
|
||||
your needs.
|
||||
|
||||
|
||||
findRegressions-nightly.py
|
||||
@ -100,9 +111,12 @@ Test Suite
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Follow the `LNT Quick Start Guide <http://llvm.org/docs/lnt/quickstart.html>`__ link on how to set-up the test-suite
|
||||
Follow the `LNT Quick Start Guide
|
||||
<http://llvm.org/docs/lnt/quickstart.html>`__ link on how to set-up the
|
||||
test-suite
|
||||
|
||||
The binary location you'll have to use for testing is inside the ``rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install``.
|
||||
The binary location you'll have to use for testing is inside the
|
||||
``rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install``.
|
||||
Link that directory to an easier location and run the test-suite.
|
||||
|
||||
An example on the run command line, assuming you created a link from the correct
|
||||
@ -116,13 +130,16 @@ install directory to ``~/devel/llvm/install``::
|
||||
--cc ~/devel/llvm/install/bin/clang \
|
||||
--cxx ~/devel/llvm/install/bin/clang++
|
||||
|
||||
It should have no new regressions, compared to the previous release or release candidate. You don't need to fix
|
||||
all the bugs in the test-suite, since they're not necessarily meant to pass on all architectures all the time. This is
|
||||
due to the nature of the result checking, which relies on direct comparison, and most of the time, the failures are
|
||||
related to bad output checking, rather than bad code generation.
|
||||
It should have no new regressions, compared to the previous release or release
|
||||
candidate. You don't need to fix all the bugs in the test-suite, since they're
|
||||
not necessarily meant to pass on all architectures all the time. This is
|
||||
due to the nature of the result checking, which relies on direct comparison,
|
||||
and most of the time, the failures are related to bad output checking, rather
|
||||
than bad code generation.
|
||||
|
||||
If the errors are in LLVM itself, please report every single regression found as blocker, and all the other bugs
|
||||
as important, but not necessarily blocking the release to proceed. They can be set as "known failures" and to be
|
||||
If the errors are in LLVM itself, please report every single regression found
|
||||
as blocker, and all the other bugs as important, but not necessarily blocking
|
||||
the release to proceed. They can be set as "known failures" and to be
|
||||
fix on a future date.
|
||||
|
||||
.. _pre-release-process:
|
||||
@ -134,23 +151,26 @@ Pre-Release Process
|
||||
:local:
|
||||
|
||||
When the release process is announced on the mailing list, you should prepare
|
||||
for the testing, by applying the same testing you'll do on the release candidates,
|
||||
on the previous release.
|
||||
for the testing, by applying the same testing you'll do on the release
|
||||
candidates, on the previous release.
|
||||
|
||||
You should:
|
||||
|
||||
* Download the previous release sources from http://llvm.org/releases/download.html.
|
||||
* Download the previous release sources from
|
||||
http://llvm.org/releases/download.html.
|
||||
|
||||
* Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to ``-final``).
|
||||
* Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to
|
||||
``-final``).
|
||||
|
||||
* Once all three stages are done, it'll test the final stage.
|
||||
|
||||
* Using the ``Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.install`` base, run the test-suite.
|
||||
* Using the ``Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.install`` base,
|
||||
run the test-suite.
|
||||
|
||||
If the final phase's ``make check-all`` failed, it's a good idea to also test the
|
||||
intermediate stages by going on the obj directory and running ``make check-all`` to find
|
||||
if there's at least one stage that passes (helps when reducing the error for bug report
|
||||
purposes).
|
||||
If the final phase's ``make check-all`` failed, it's a good idea to also test
|
||||
the intermediate stages by going on the obj directory and running
|
||||
``make check-all`` to find if there's at least one stage that passes (helps
|
||||
when reducing the error for bug report purposes).
|
||||
|
||||
.. _release-process:
|
||||
|
||||
@ -166,22 +186,23 @@ to them), and run the release test as above.
|
||||
|
||||
You should:
|
||||
|
||||
* Download the current candidate sources from where the release manager points you
|
||||
(ex. http://llvm.org/pre-releases/3.3/rc1/).
|
||||
* Download the current candidate sources from where the release manager points
|
||||
you (ex. http://llvm.org/pre-releases/3.3/rc1/).
|
||||
|
||||
* Repeat the steps above with ``-rc 1``, ``-rc 2`` etc modes and run the test-suite
|
||||
the same way.
|
||||
* Repeat the steps above with ``-rc 1``, ``-rc 2`` etc modes and run the
|
||||
test-suite the same way.
|
||||
|
||||
* Compare the results, report all errors on Bugzilla and publish the binary blob
|
||||
where the release manager can grab it.
|
||||
|
||||
Once the release manages announces that the latest candidate is the good one, you
|
||||
have to pack the ``Release`` (no Asserts) install directory on ``Phase3`` and that
|
||||
will be the official binary.
|
||||
Once the release manages announces that the latest candidate is the good one,
|
||||
you have to pack the ``Release`` (no Asserts) install directory on ``Phase3``
|
||||
and that will be the official binary.
|
||||
|
||||
* Rename (or link) ``clang+llvm-REL-ARCH-ENV`` to the .install directory
|
||||
|
||||
* Tar that into the same name with ``.tar.gz`` extensioan from outside the directory
|
||||
* Tar that into the same name with ``.tar.gz`` extensioan from outside the
|
||||
directory
|
||||
|
||||
* Make it available for the release manager to download
|
||||
|
||||
@ -196,15 +217,15 @@ Bug Reporting Process
|
||||
If you found regressions or failures when comparing a release candidate with the
|
||||
previous release, follow the rules below:
|
||||
|
||||
* Critical bugs on compilation should be fixed as soon as possible, possibly before
|
||||
releasing the binary blobs.
|
||||
* Critical bugs on compilation should be fixed as soon as possible, possibly
|
||||
before releasing the binary blobs.
|
||||
|
||||
* Check-all tests should be fixed before the next release candidate, but can wait
|
||||
until the test-suite run is finished.
|
||||
* Check-all tests should be fixed before the next release candidate, but can
|
||||
wait until the test-suite run is finished.
|
||||
|
||||
* Bugs in the test suite or unimportant check-all tests can be fixed in between
|
||||
release candidates.
|
||||
|
||||
* New features or recent big changes, when close to the release, should have done
|
||||
in a way that it's easy to disable. If they misbehave, prefer disabling them than
|
||||
releasing an unstable (but untested) binary package.
|
||||
* New features or recent big changes, when close to the release, should have
|
||||
done in a way that it's easy to disable. If they misbehave, prefer disabling
|
||||
them than releasing an unstable (but untested) binary package.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user