In particular, say clearly that X.Y-unstable should be thus, not
X.Y.0-unstable.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Provide a rune, following which a magit selective git add
(or git add -p) can be used to commit the appropriate changes.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
It is only necessary to change Config.mk if it refers to unstable
branches anywhere. This time, for example, it didn't.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Fix text about release cycle. Drop the conjured up example that's no
longer applicable.
Signed-off-by: Wei Liu <wl@xen.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In order to have a link to the release notes in the feature list
generated from SUPPORT.md add that link in the "Release Support"
section of that file.
The real link needs to be adapted when the version is being released.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Document two steps which were done this time, and last time:
(i) setting off an early osstest run
(ii) sending the mail confirming it's done.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Split out the required work for the new and old branches and be more
specific about what is to be done. In the RT checklist, reformat and
expand the "turn off debug" instructions.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
* Drop reference to long-gone Citrix-internal HG trees
* Drop reference to RT-accessible web pages; web page editing
is now handled via the RM, community manager, etc.
* Drop reference to git description files; this is not needed
because now we have one tree with all branches, not one per branch
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
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: Julien Grall <julien.grall@arm.com>
Acked-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Lars Kurth <lars.kurth@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Preparing a real release, not just an RC, involves making commits.
Typically, those will be on staging-$x. The tag will refer to them,
and the checklist already says to push them to xenbits.
But if the *branch* is not pushed, then people who just "git fetch"
won't get the tag because it refers to commits they don't have.
(Because of the strange rules git has about tag fetching.)
Worse, the same may be true of people who "git clone".
And anyway, those commits *should* be fed to staging-$x.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
The old instructions were obsolete. Here are the details I used when
branching for 4.10.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Clarify what is expected of the release technician for SUPPORT.md: fix
the version number field. The support dates will be set by the
release manageer.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
This contains instructions and shell runes for the Release Technician,
who is the person doing the technical admin to construct the release,
fork branches, make tags and tarballs, etc.
Rename it to make this clearer.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
Ian Jackson