<li><a href="#overview">Overview</a>
<li><a href="#schedule">Release schedule</a>
<li><a href="#pickntest">Cherry-pick and test</a>
+<li><a href="#stagingbranch">Staging branch</a>
<li><a href="#branch">Making a branchpoint</a>
<li><a href="#prerelease">Pre-release announcement</a>
<li><a href="#release">Making a new release</a>
-<li><a href="#calendar">Update the calendar</a>
<li><a href="#announce">Announce the release</a>
<li><a href="#website">Update the mesa3d.org website</a>
<li><a href="#bugzilla">Update Bugzilla</a>
<h1 id="schedule">Release schedule</h1>
<p>
-Releases should happen on Fridays. Delays can occur although those should be keep
-to a minimum.
+Releases should happen on Wednesdays. Delays can occur although those
+should be kept to a minimum.
<br>
-See our <a href="release-calendar.html" target="_parent">calendar</a> for the
+See our <a href="release-calendar.html" target="_parent">calendar</a>
+for information about how the release schedule is planned, and the
date and other details for individual releases.
</p>
<li>Available approximately every three months.
<li>Initial timeplan available 2-4 weeks before the planned branchpoint (rc1)
on the mesa-announce@ mailing list.
+<li>Typically, the final release will happen after 4
+candidates. Additional ones may be needed in order to resolve blocking
+regressions, though.
<li>A <a href="#prerelease">pre-release</a> announcement should be available
approximately 24 hours before the final (non-rc) release.
</ul>
<br>
The final release from the 12.0 series Mesa 12.0.5 will be out around the same
time (or shortly after) 13.0.1 is out.
+<br>
+This also involves that, as a final release may be delayed due to the
+need of additional candidates to solve some blocking regression(s),
+the release manager might have to update
+the <a href="release-calendar.html" target="_parent">calendar</a> with
+additional bug fix releases of the current stable branch.
</p>
<p>
Nomination happens in the mesa-stable@ mailing list. However,
-maintainer is resposible of checking for forgotten candidates in the
+maintainer is responsible of checking for forgotten candidates in the
master branch. This is achieved by a combination of ad-hoc scripts and
a casual search for terms such as regression, fix, broken and similar.
</p>
<p>Done continuously up-to the <a href="#prerelease">pre-release</a> announcement.</p>
<p>
-As an exception, patches can be applied up-to the last ~1h before the actual
-release. This is made <strong>only</strong> with explicit permission/request,
-and the patch <strong>must</strong> be very well contained. Thus it cannot
-affect more than one driver/subsystem.
+Developers can request, <em>as an exception</em>, patches to be applied up-to
+the last one hour before the actual release. This is made <strong>only</strong>
+with explicit permission/request, and the patch <strong>must</strong> be very
+well contained. Thus it cannot affect more than one driver/subsystem.
</p>
-<p>
-Currently Ilia Mirkin and AMD devs have requested "permanent" exception.
-</p>
+<p>Following developers have requested permanent exception</p>
+<ul>
+<li><em>Ilia Mirkin</em>
+<li><em>AMD team</em>
+</ul>
+<p>The following must pass:</p>
<ul>
-<li>make distcheck, scons and scons check must pass
+<li>make distcheck, scons and scons check
<li>Testing with different version of system components - LLVM and others is also
performed where possible.
<li>As a general rule, testing with various combinations of configure
</ul>
<p>
-Achieved by combination of local ad-hoc scripts, mingw-w64 cross
-compilation and AppVeyor plus Travis-CI, the latter as part of their
-Github integration.
+These are achieved by combination of <a href="basictesting">local testing</a>,
+which includes mingw-w64 cross compilation and AppVeyor plus Travis-CI, the
+latter two as part of their Github integration.
</p>
<p>
idea too.
</p>
+<h1 id="stagingbranch">Staging branch</h1>
+
+<p>
+A live branch, which contains the currently merge/rejected patches is available
+in the main repository under <code>staging/X.Y</code>. For example:
+</p>
+<pre>
+ staging/18.1 - WIP branch for the 18.1 series
+ staging/18.2 - WIP branch for the 18.2 series
+</pre>
+
+<p>
+Notes:
+</p>
+<ul>
+<li>People are encouraged to test the staging branch and report regressions.</li>
+<li>The branch history is not stable and it <strong>will</strong> be rebased,</li>
+</ul>
+
<h1 id="branch">Making a branchpoint</h1>
release is made.
</p>
+<p>
+Be aware to add a note to warn about a final release in a series, if
+that is the case.
+</p>
+
<h2>Terminology used</h2>
<ul><li>Nominated</ul>
- NUMBER nominated (outstanding)
- and NUMBER rejected patches
+[If applicable:
+Note: this is the final anticipated release in the SERIES series. Users are
+encouraged to migrate to the NEXT_SERIES series in order to obtain future fixes.]
+
BRIEF SUMMARY OF CHANGES
Take a look at section "Mesa stable queue" for more information.
AUTHOR (NUMBER):
COMMIT SUMMARY
+[If applicable:
+Squashed with
+ COMMIT SUMMARY]
For example:
Squashed with
ralloc: don't leave out the alignment factor
+
Rejected (NUMBER)
=================
-Rejected (11)
-=============
-
AUTHOR (NUMBER):
SHA COMMIT SUMMARY
Reason: ...
+
+For example:
+
+Emil Velikov (1)
+ a39ad18 configure.ac: honour LLVM_LIBDIR when linking against LLVM
+
+Reason: The patch was reverted shortly after it was merged.
</pre>
relevant branch.
</p>
-<h3>Perform basic testing</h3>
+<h3 id="basictesting">Perform basic testing</h3>
<p>
Most of the testing should already be done during the
</p>
<pre>
+ # Set MAKEFLAGS if you haven't already
git clean -fXd; git clean -nxd
read # quick cross check any outstanding files
export __version=`cat VERSION`
chmod 755 -fR $__build_root; rm -rf $__build_root
mkdir -p $__build_root && cd $__build_root
- # For the distcheck, you may want to specify which LLVM to use:
+ # For the native builds - such as distcheck, scons, sanity test, you
+ # may want to specify which LLVM to use:
# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
- $__mesa_root/autogen.sh && make -j2 distcheck
+
+ # Do a full distcheck
+ $__mesa_root/autogen.sh && make distcheck
# Build check the tarballs (scons, linux)
tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
cd .. && rm -rf mesa-$__version
# Build check the tarballs (scons, windows/mingw)
- # You may need to unset LLVM if you set it before:
- # unset LLVM_CONFIG
+ # Temporary drop LLVM_CONFIG, unless you have a Windows/mingw one.
+ # save_LLVM_CONFIG=`echo $LLVM_CONFIG`; unset LLVM_CONFIG
tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
scons platform=windows toolchain=crossmingw
cd .. && rm -rf mesa-$__version
# Test the automake binaries
+ # Restore LLVM_CONFIG, if applicable:
+ # export LLVM_CONFIG=`echo $save_LLVM_CONFIG`; unset save_LLVM_CONFIG
tar -xaf mesa-$__version.tar.xz && cd mesa-$__version
- # You may want to specify which LLVM to use:
./configure \
--with-dri-drivers=i965,swrast \
--with-gallium-drivers=swrast \
--with-vulkan-drivers=intel \
--enable-llvm-shared-libs \
--enable-llvm \
- --with-llvm-prefix=/usr/lib/llvm-3.9 \
--enable-glx-tls \
--enable-gbm \
--enable-egl \
--with-platforms=x11,drm,wayland,surfaceless
- make -j2 && DESTDIR=`pwd`/test make -j6 install
- __glxinfo_cmd='glxinfo 2>&1 | egrep -o "Mesa.*|Gallium.*|.*dri\.so"'
- __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
- __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
- __es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
- export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/
+ make && DESTDIR=`pwd`/test make install
+
+ # Drop LLVM_CONFIG, if applicable:
+ # unset LLVM_CONFIG
+
+ __glxinfo_cmd='glxinfo 2>&1 | egrep -o "Mesa.*|Gallium.*|.*dri\.so"'
+ __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"'
+ __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"'
+ __es2gears_cmd='es2gears_x11 2>&1 | grep -v "configuration file"'
+ test "x$LD_LIBRARY_PATH" != 'x' && __old_ld="$LD_LIBRARY_PATH"
+ export LD_LIBRARY_PATH=`pwd`/test/usr/local/lib/:"${__old_ld}"
export LIBGL_DRIVERS_PATH=`pwd`/test/usr/local/lib/dri/
export LIBGL_DEBUG=verbose
eval $__glxinfo_cmd
eval $__glxgears_cmd
eval $__es2info_cmd
eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=1
+ export LIBGL_ALWAYS_SOFTWARE=true
eval $__glxinfo_cmd
eval $__glxgears_cmd
eval $__es2info_cmd
eval $__es2gears_cmd
- export LIBGL_ALWAYS_SOFTWARE=1
+ export LIBGL_ALWAYS_SOFTWARE=true
export GALLIUM_DRIVER=softpipe
eval $__glxinfo_cmd
eval $__glxgears_cmd
eval $__es2gears_cmd
# Smoke test DOTA2
unset LD_LIBRARY_PATH
+ test "x$__old_ld" != 'x' && export LD_LIBRARY_PATH="$__old_ld" && unset __old_ld
unset LIBGL_DRIVERS_PATH
unset LIBGL_DEBUG
unset LIBGL_ALWAYS_SOFTWARE
+ unset GALLIUM_DRIVER
export VK_ICD_FILENAMES=`pwd`/src/intel/vulkan/dev_icd.json
steam steam://rungameid/570 -vconsole -vulkan
+ unset VK_ICD_FILENAMES
</pre>
<h3>Update version in file VERSION</h3>
</pre>
<p>
-Also, edit docs/relnotes.html to add a link to the new release notes, and edit
-docs/index.html to add a news entry. Then commit and push:
+Also, edit docs/relnotes.html to add a link to the new release notes,
+edit docs/index.html to add a news entry and a note in case of the
+last release in a series, and remove the version from
+docs/release-calendar.html. Then commit and push:
</p>
<pre>
- git commit -as -m "docs: add news item and link release notes for X.Y.Z"
+ git commit -as -m "docs: update calendar, add news item and link release notes for X.Y.Z"
git push origin master X.Y
</pre>
-<h1 id="calendar">Update the calendar</h1>
+<h1 id="announce">Announce the release</h1>
<p>
-Remove the version from the <a href="release-calendar.html" target="_parent">calendar</a>.
+Use the generated template during the releasing process.
</p>
-
-<h1 id="announce">Announce the release</h1>
-
<p>
-Use the generated template during the releasing process.
+Again, pay attention to add a note to warn about a final release in a
+series, if that is the case.
</p>