From: Dylan Baker Date: Thu, 5 Mar 2020 18:31:22 +0000 (-0800) Subject: docs: Update release notes with current process X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=d4cb9ef8260ced0a5693db18dedbdd11cbcfa7e6;p=mesa.git docs: Update release notes with current process There's a lot of stuff here that's out of date, update it to something more modern. Reviewed-by: Eric Engestrom Tested-by: Marge Bot Part-of: --- diff --git a/docs/releasing.html b/docs/releasing.html index 644486bf37b..e5a453799bb 100644 --- a/docs/releasing.html +++ b/docs/releasing.html @@ -23,7 +23,6 @@
  • Cherry-pick and test
  • Staging branch
  • Making a branchpoint -
  • Pre-release announcement
  • Making a new release
  • Announce the release
  • Update Gitlab Issues @@ -74,16 +73,11 @@ on the mesa-announce@ mailing list.
  • Typically, the final release will happen after 4 candidates. Additional ones may be needed in order to resolve blocking regressions, though. -
  • A pre-release announcement should be available -approximately 24 hours before the final (non-rc) release. -

    Stable releases

    • Normally available once every two weeks.
    • Only the latest branch has releases. See note below. -
    • A pre-release announcement should be available -approximately 48 hours before the actual release.

    @@ -113,20 +107,24 @@ described in the same section.

    -Nomination happens in the mesa-stable@ mailing list. However, -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. +Nominations happen via special tags in the commit messages, and via gitlab +merge requests against the staging branches. There are special scripts used +to read the tags.

    -Maintainer is also responsible for testing in various possible permutations of -the meson and scons build. +The maintainer should watch or be in contact with the Intel CI team, as well +as watch the gitlab CI for regressions.

    -

    Cherry-picking and build/check testing

    +

    +Cherry picking should be done with the '-x' switch (to automatically add +"cherry picked from ..." to the commit message): +

    -

    Done continuously up-to the pre-release announcement.

    + +git cherry-pick -x abcdef12345667890 +

    Developers can request, as an exception, patches to be applied up-to @@ -141,20 +139,7 @@ well contained. Thus it cannot affect more than one driver/subsystem.

  • AMD team -

    The following must pass:

    -
      -
    • meson test, scons and scons check -
    • Testing with different version of system components - LLVM and others is also -performed where possible. -
    • As a general rule, testing with various combinations of configure -switches, depending on the specific patchset. -
    - -

    -These are achieved by combination of local testing, -which includes mingw-w64 cross compilation and AppVeyor plus Travis-CI, the -latter two as part of their Github integration. -

    +

    The gitlab CI must pass.

    For Windows related changes, the main contact point is Brian @@ -178,10 +163,6 @@ fix(es), then they should be squashed together. The commit messages and the "cherry picked from"-tags must be preserved.

    -

    -This should be noted in the pre-announce email. -

    - 
     git show b10859ec41d09c57663a258f43fe57c12332698e
 
@@ -208,27 +189,12 @@ Date:   Wed Mar 1 18:11:10 2017 +0100
 
 
    Regression/functionality testing
    
 
-
    
-Less often (once or twice), shortly before the pre-release announcement.
-Ensure that testing is redone if Intel devs have requested an exception, as per above.
-
    
-
 
      
 
    • no regressions should be observed for Piglit/dEQP/CTS/Vulkan on Intel platforms
 
    • no regressions should be observed for Piglit using the swrast, softpipe
 and llvmpipe drivers
 
    
 
-
    
-Currently testing is performed courtesy of the Intel OTC team and their Jenkins CI setup. Check with the Intel team over IRC how to get things setup.
-
    
-
-
    
-Installing the built driver from the pre-announced RC branch in the
-system and making some every day's use until the release may be a good
-idea too.
-
    
-
 
    Staging branch
    
 
 
    
@@ -277,8 +243,8 @@ git checkout -b X.Y
 git checkout master
 $EDITOR VERSION # bump the version number
 git commit -as
-cp docs/relnotes/{X.Y,X.Y+1}.html # copy/create relnotes template
-git commit -as
+truncate docs/relnotes/new_features.txt
+git commit -a
 git push origin X.Y-branchpoint X.Y
    @@ -293,162 +259,6 @@ For example: files being overwritten on install, etc. Happens extremely rarely - we had only one case so far (see commit 2ced8eb136528914e1bf4e000dea06a9d53c7e04).

    -

    -Proceed to release -rc1. -

    - - -

    Pre-release announcement

    - -

    -It comes shortly after outstanding patches in the respective branch are pushed. -Developers can check, in brief, what's the status of their patches. They, -alongside very early testers, are strongly encouraged to test the branch and -report any regressions. -

    -

    -It is followed by a brief period (normally 24 or 48 hours) before the actual -release is made. -

    - -

    -Be aware to add a note to warn about a final release in a series, if -that is the case. -

    - -

    Terminology used

    - -
    • Nominated
    - -

    -Patch that is nominated but yet to to merged in the patch queue/branch. -

    - -
    • Queued
    - -

    -Patch is in the queue/branch and will feature in the next release. -Barring reported regressions or objections from developers. -

    - -
    • Rejected
    - -

    -Patch does not fit the -criteria and -is followed by a brief information. The release maintainer is human so if you -believe you've spotted a mistake do let them know. -

    - -

    Format/template

    -
    -Subject: [ANNOUNCE] Mesa X.Y.Z release candidate
-To: mesa-announce@...
-Cc: mesa-dev@...
-
-Hello list,
-
-The candidate for the Mesa X.Y.Z is now available. Currently we have:
- - NUMBER queued
- - 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.
-
-
-Testing reports/general approval
---------------------------------
-Any testing reports (or general approval of the state of the branch) will be
-greatly appreciated.
-
-The plan is to have X.Y.Z this DAY (DATE), around or shortly after TIME.
-
-If you have any questions or suggestions - be that about the current patch
-queue or otherwise, please go ahead.
-
-
-Trivial merge conflicts
------------------------
-List of commits where manual intervention was required.
-Keep the authors in the CC list.
-
-commit SHA
-Author: AUTHOR
-
-    COMMIT SUMMARY
-
-    CHERRY PICKED FROM
-
-
-For example:
-
-commit 990f395e007c3204639daa34efc3049f350ee819
-Author: Emil Velikov <emil.velikov@collabora.com>
-
-    anv: automake: cleanup the generated json file during make clean
-
-    (cherry picked from commit 8df581520a823564be0ab5af7dbb7d501b1c9670)
-
-
-Cheers,
-Emil
-
-
-Mesa stable queue
------------------
-
-Nominated (NUMBER)
-==================
-
-AUTHOR (NUMBER):
-      SHA     COMMIT SUMMARY
-
-For example:
-
-Dave Airlie (1):
-      2de85eb radv: fix texturesamples to handle single sample case
-
-
-Queued (NUMBER)
-===============
-
-AUTHOR (NUMBER):
-      COMMIT SUMMARY
-[If applicable:
-Squashed with
-      COMMIT SUMMARY]
-
-For example:
-
-Jonas Pfeil (1):
-      ralloc: Make sure ralloc() allocations match malloc()'s alignment.
-Squashed with
-      ralloc: don't leave out the alignment factor
-
-
-Rejected (NUMBER)
-=================
-
-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.
-
    - -

    Making a new release

    @@ -466,8 +276,7 @@ relevant branch.

    Most of the testing should already be done during the -cherry-pick and -pre-announce stages. +cherry-pick So we do a quick 'touch test'

    @@ -521,13 +330,11 @@ unset VK_ICD_FILENAMES

    The release notes are completely generated by the bin/gen_release_notes.py script. Simply run this script before -bumping the version +bumping the version, and commit the results. The only thing left to do is add the sha256 sums.

    -

    Update version in file VERSION

    -

    Increment the version contained in the file VERSION at Mesa's top-level, then commit this change. @@ -549,8 +356,6 @@ Start the release process. 

    -# For the dist/distcheck, you may want to specify which LLVM to use:
-# export LLVM_CONFIG=/usr/lib/llvm-3.9/bin/llvm-config
 ../relative/path/to/release.sh . # append --dist if you've already done distcheck above
    @@ -562,7 +367,7 @@ and SSH passphrase(s) to sign and upload the files, respectively.

    Add the sha256sums to the release notes

    -Edit docs/relnotes/X.Y.Z.html to add the sha256sums as available in the mesa-X.Y.Z.announce template. Commit this change. +Edit docs/relnotes/X.Y.Z.html to add the sha256sum as available in the mesa-X.Y.Z.announce template. Commit this change.

    Back on mesa master, add the new release notes into the tree

    @@ -578,7 +383,8 @@ git cherry-pick -x X.Y

    Then run the ./bin/post_verison.py X.Y.Z, where X.Y.Z is the version you just made. This will updated docs/relnotes.html and -docs/index.html. Remove docs/release-calendar.html. Then commit and push: +docs/index.html. Remove the new release from docs/release-calendar.html. Then +commit and push: