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>
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>
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>
Juergen Gross
Ian Jackson