--- docs/releasing.html | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
diff --git a/docs/releasing.html b/docs/releasing.html index 07f100caae1..20fc4579a32 100644 --- a/docs/releasing.html +++ b/docs/releasing.html @@ -249,6 +249,25 @@ Now go to <a href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa"; target="_parent">Bugzilla</a> and add the new Mesa version X.Y. </p> +<p> +Use a stanging branch: +</p> +<pre> + git checkout X.Y + git checkout -b X.Y-proposed +</pre> +<p> +This branch should be reported to any teams using a CI to track upcoming stable +branches. This will allow that team to report an CI regressions to the release +manager, while leaving the X.Y branch in a continuously usable state. To +that end it is most useful if the release manager run the relavent scripts +(such as git-fixes-pick-list.sh) once per day, and update this branch. When it is +time to make a release, the X.Y branch should be rebased to the X.Y-proposed branch. + +The staging branch can be force pushed (for example, to remove a patch that +causes regressions), while the X.Y should not be force pushed. +</p> + <p> Check that there are no distribution breaking changes and revert them if needed. For example: files being overwritten on install, etc. Happens extremely rarely - -- 2.17.0 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
