Anastasia Klimchuk has uploaded this change for review.
doc: Add doc describing release process
Change-Id: Id6aacf5ef3879a5e236759e7a4a6af3cf7cc0a00
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
---
M doc/dev_guide/index.rst
A doc/dev_guide/release_process.rst
M doc/how_to_support_flashrom.rst
3 files changed, 103 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/flashrom refs/changes/62/83762/1
diff --git a/doc/dev_guide/index.rst b/doc/dev_guide/index.rst
index 57cd846..6aa65be 100644
--- a/doc/dev_guide/index.rst
+++ b/doc/dev_guide/index.rst
@@ -7,3 +7,4 @@
building_from_source
building_with_make
development_guide
+ release_process
diff --git a/doc/dev_guide/release_process.rst b/doc/dev_guide/release_process.rst
new file mode 100644
index 0000000..749779e
--- /dev/null
+++ b/doc/dev_guide/release_process.rst
@@ -0,0 +1,100 @@
+===============
+Release process
+===============
+
+The document describes the technical aspect of making a flashrom release,
+and it assumes that the team of active core maintainers is in agreement to commence the process.
+
+To go through the process, at least two maintainers are needed to be closely involved,
+because it includes sending and approving patches in Gerrit.
+
+Set up the timeline and announce on the mailing list
+====================================================
+
+Decide on the bug-fixing and testing window (3-4 weeks), decide exact dates of start and end of the window,
+and announce it on the mailing list. Ideally make an announcement a few weeks in advance.
+
+During the testing and bug-fixing window only bug fixes are merged, and no new features are added.
+Typically it's fine to push new features for review, and reviews are fine too,
+but merging new features will be delayed until the release is done.
+*This should be very clearly explained in the announcement.*
+
+Start testing and bug-fixing window
+===================================
+
+* Double-check and merge all the patches that are fully ready (see also :ref:`merge-checklist`)
+
+* Update VERSION file to first release candidate. Check the git history of VERSION file for a version name pattern.
+
+ * As an example at the time of writing, the version name of the first release candidate was ``1.4.0-rc1``.
+ * To update the VERSION file, push a patch to Gerrit, and another maintainer should review and approve.
+
+* After submitting the change to the VERSION file, tag this commit.
+ You can check `flashrom tags in Gerrit <https://review.coreboot.org/admin/repos/flashrom,tags,25>`_
+ for tag name pattern. As an example at the time of writing, the tag name was ``v1.4.0-rc1``.
+
+* Write an announcement on the mailing list. Be very clear about:
+
+ * start and end date of the window, and what does it mean
+ * any help with :ref:`building-and-testing` is very much appreciated
+
+**From this moment and until the release cut, the highest priority is for building and testing on various environments, and bug-fixing.**
+
+Release candidates
+==================
+
+If any bugs are found and fixed (or reverted), then the second, or third release candidate will be needed.
+The process is the same as with the first candidate:
+
+* Update the VERSION file, and submit this
+* Tag the commit which updates the VERSION file
+* Post an announcement on mailing list
+
+Release notes
+=============
+
+During the time in-between releases, ideally most updates are accumulated in the doc :doc:`/release_notes/devel`.
+While this doc is helpful, it is not a replacement for a human to go through all development history
+since the previous release and prepare release notes. One maintainer is preparing the release notes
+and sending them for review, and at least one other maintainer needs to review that (it can be more than one reviewer).
+
+Ideally the patch with release notes should be prepared, reviewed and approved before the release cut,
+so that it can be published by the time of final release announcement.
+
+For inspiration to write release notes, have a look at prior art :doc:`/release_notes/index`.
+
+There is one section in release notes, Download, which is not possible to complete before the actual release cut.
+Leave it as TODO, but complete the rest.
+
+Cut the release
+===============
+
+Wait for at least a week (or two) since the last release candidate. if everything is alright:
+
+* Submit the release notes, and in the same patch restart :doc:`/release_notes/devel` document.
+ This way everyone who is syncing the repository by the release tag will have release notes in the tree.
+
+* Update VERSION file to release version (for example, at the time of writing ``1.4.0``), and submit this
+
+* Tag the commit which updates the VERSION file. You can check
+ `flashrom tags in Gerrit <https://review.coreboot.org/admin/repos/flashrom,tags,25>`_ for tag name pattern.
+ As an example at the time of writing, the tag name was ``v1.4.0``.
+
+* Create the tarball, sign it, and upload to the server together with the signature.
+
+* Update release notes with the link to download tarball, signature, and fingerprint. Submit this and check that final release notes are published on the website.
+
+* Write the release announcement, don't forget to:
+
+ * Link to download the tarball, signature and fingerprint.
+ * Say thank you to everyone who is helping and supporting flashrom
+ * Add link to published release notes on the website
+
+Start the next cycle of development
+===================================
+
+* Update the VERSION file to the development version. For example, at the time of writing ``1.5.0-devel``, and submit this.
+
+* Submit all the patches that have been ready and waiting.
+
+* Celebrate :)
diff --git a/doc/how_to_support_flashrom.rst b/doc/how_to_support_flashrom.rst
index 372ef38..7fdfdf8 100644
--- a/doc/how_to_support_flashrom.rst
+++ b/doc/how_to_support_flashrom.rst
@@ -63,6 +63,8 @@
You can check pending patches under review `in Gerrit <https://review.coreboot.org/q/status:open+project:flashrom>`_
and help with code review if a patch looks useful, you understand what it is about, and want to have it submitted.
+.. _building-and-testing:
+
Building and testing
====================
To view, visit change 83762. To unsubscribe, or for help writing mail filters, visit settings.