[Xen-devel] [PATCH v2 2/2] docs/process/xen-release-management: Lesson to learn

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

The 4.10 release preparation was significantly more hairy than ideal.
(We seem to have a good overall outcome despite, rather than because
of, our approach.)

This is the second time (at least) that we have come close to failure
by committing to a release date before the exact code to be released
is known and has been made and tested.

Evidently our docs makes it insufficiently clear not to do that.

CC: Lars Kurth <lars.kurth@xxxxxxxxxx>
CC: Julien Grall <julien.grall@xxxxxxx>
Acked-by: Juergen Gross <jgross@xxxxxxxx>
Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
---
 docs/process/xen-release-management.pandoc | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/docs/process/xen-release-management.pandoc 
b/docs/process/xen-release-management.pandoc
index 2ff0665..eee5dcf 100644
--- a/docs/process/xen-release-management.pandoc
+++ b/docs/process/xen-release-management.pandoc
@@ -211,6 +211,11 @@ https://wiki.xenproject.org/wiki/Category:Xen_4.9
     Ask them to dry-run their checklist and confirm everything is OK. If not,
     arrange another RC and restart this checklist.
 
+7. Do not commit to a release date until
+
+    * The exact xen.git commit id to be released is known.
+    * That commit id has been satisfactorily tested.
+
 7. Give PR Personnel final go-ahead, and instruct Release Technician to make
 release deliverables (tags and tarballs - will usually be in place the day
 before the release). At this point, PR collateral will be sent to reporters
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel