On Monday, 2018-05-21 10:34:54 -0700, Dylan Baker wrote: > --- > 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
Might be worth adding a section with a list of the CI teams and their contact person? Series (with typo fixes already mentioned by others) is: Reviewed-by: Eric Engestrom <eric.engest...@intel.com> > +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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
