Message ID | 20180212124008.8960-1-cohuck@redhat.com |
---|---|
State | New |
Headers | show |
Series | [v2] docs: document our stable process | expand |
On 02/12/2018 06:40 AM, Cornelia Huck wrote: > Some pointers on how to get a patch into stable. > > [contains some suggestions by mdroth] > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > RFC/D->v2: added mdroth's suggestions > --- > docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 docs/stable-process.rst > > + Cc: qemu-stable@nongnu.org > + > + to the patch description. By default, this will send a copy of the patch Spurious double space. > + to ``qemu-stable@nongnu.org`` if you use git send-email, which is where > + patches that are stable candidates are tracked by the maintainers. > + > +Stable release process > +---------------------- > + > +When the stable maintainers prepare a new stable release, they will prepare > +a git branch with a release candidate and send the patches out to > +``qemu-devel@nongnu.org`` for review. If any of your patches are included, > +please verify that they look fine. Maybe add: especially if the maintainer had to tweak the patch as part of back-porting things across branches. > You may also nominate other patches that > +you think are suitable for inclusion. After review is complete (may involve > +more release candidates), a new stable release is made available. > What you have is an obvious improvement over the "nothing" that was before, so whether or not you fold in my additional comments, you can add: Reviewed-by: Eric Blake <eblake@redhat.com>
On Mon, 12 Feb 2018 11:17:38 -0600 Eric Blake <eblake@redhat.com> wrote: > On 02/12/2018 06:40 AM, Cornelia Huck wrote: > > Some pointers on how to get a patch into stable. > > > > [contains some suggestions by mdroth] > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > --- > > RFC/D->v2: added mdroth's suggestions > > --- > > docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > create mode 100644 docs/stable-process.rst > > > What you have is an obvious improvement over the "nothing" that was > before, so whether or not you fold in my additional comments, you can add: > > Reviewed-by: Eric Blake <eblake@redhat.com> Your comments make sense, so I've folded them in. Thanks!
Quoting Cornelia Huck (2018-02-12 06:40:08) > Some pointers on how to get a patch into stable. > > [contains some suggestions by mdroth] > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > RFC/D->v2: added mdroth's suggestions > --- > docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 docs/stable-process.rst > > diff --git a/docs/stable-process.rst b/docs/stable-process.rst > new file mode 100644 > index 0000000000..c571204c9f > --- /dev/null > +++ b/docs/stable-process.rst > @@ -0,0 +1,67 @@ > +QEMU and the stable process > +=========================== > + > +QEMU stable releases > +-------------------- > + > +QEMU stable releases are based upon the last released QEMU version > +and marked by an additional version number, e.g. 2.10.1. Occasionally, > +a four-number version is released, if a single urgent fix needs to go > +on top. > + > +Usually, stable releases are only provided for the last major QEMU > +release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y > +stable releases are produced only until QEMU 2.12.0 is released, at > +which the stable process moves to producing 2.12.x/2.12.x.y releases. "at which point" Sorry, looks like one of my errors slipped through :) With that and Eric's suggestions addressed: Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> > + > +What should go into a stable release? > +------------------------------------- > + > +Generally, the following patches are considered stable material: > +- Patches that fix severe issues, like fixes for CVEs > +- Patches that fix regressions > + > +If you think the patch would be important for users of the current release > +(or for a distribution picking fixes), it is usually a good candidate > +for stable. > + > + > +How to get a patch into QEMU stable > +----------------------------------- > + > +There are various ways to get a patch into stable: > + > +* Preferred: Make sure that the stable maintainers are on copy when you send > + the patch by adding > + > + .. code:: > + > + Cc: qemu-stable@nongnu.org > + > + to the patch description. By default, this will send a copy of the patch > + to ``qemu-stable@nongnu.org`` if you use git send-email, which is where > + patches that are stable candidates are tracked by the maintainers. > + > +* You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy > + directly in your mail client if you think a previously submitted patch > + should be considered for a stable release. > + > +* If a maintainer judges the patch appropriate for stable later on (or you > + notify them), they will add the same line to the patch, meaning that > + the stable maintainers will be on copy on the maintainer's pull request. > + > +* If you judge an already merged patch suitable for stable, send a mail > + (preferably as a reply to the most recent patch submission) to > + ``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and > + appropriate other people (like the patch author or the relevant maintainer) > + on copy. > + > +Stable release process > +---------------------- > + > +When the stable maintainers prepare a new stable release, they will prepare > +a git branch with a release candidate and send the patches out to > +``qemu-devel@nongnu.org`` for review. If any of your patches are included, > +please verify that they look fine. You may also nominate other patches that > +you think are suitable for inclusion. After review is complete (may involve > +more release candidates), a new stable release is made available. > -- > 2.13.6 >
On 12 February 2018 at 12:40, Cornelia Huck <cohuck@redhat.com> wrote: > Some pointers on how to get a patch into stable. > > [contains some suggestions by mdroth] > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > --- > RFC/D->v2: added mdroth's suggestions > --- > docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 67 insertions(+) > create mode 100644 docs/stable-process.rst > Drive-by bikeshed comment: should this be in docs/devel ? It's aimed at QEMU developers rather than users... thanks -- PMM
On Thu, 15 Feb 2018 18:27:29 +0000 Peter Maydell <peter.maydell@linaro.org> wrote: > On 12 February 2018 at 12:40, Cornelia Huck <cohuck@redhat.com> wrote: > > Some pointers on how to get a patch into stable. > > > > [contains some suggestions by mdroth] > > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > --- > > RFC/D->v2: added mdroth's suggestions > > --- > > docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > create mode 100644 docs/stable-process.rst > > > > Drive-by bikeshed comment: should this be in docs/devel ? > It's aimed at QEMU developers rather than users... I don't mind moving the shed over to docs/devel/. OK, I have merged the various comments and pushed the result to git://github.com/cohuck/qemu stable-doc Who will merge this? I can send a pull request if needed.
diff --git a/docs/stable-process.rst b/docs/stable-process.rst new file mode 100644 index 0000000000..c571204c9f --- /dev/null +++ b/docs/stable-process.rst @@ -0,0 +1,67 @@ +QEMU and the stable process +=========================== + +QEMU stable releases +-------------------- + +QEMU stable releases are based upon the last released QEMU version +and marked by an additional version number, e.g. 2.10.1. Occasionally, +a four-number version is released, if a single urgent fix needs to go +on top. + +Usually, stable releases are only provided for the last major QEMU +release. For example, when QEMU 2.11.0 is released, 2.11.x or 2.11.x.y +stable releases are produced only until QEMU 2.12.0 is released, at +which the stable process moves to producing 2.12.x/2.12.x.y releases. + +What should go into a stable release? +------------------------------------- + +Generally, the following patches are considered stable material: +- Patches that fix severe issues, like fixes for CVEs +- Patches that fix regressions + +If you think the patch would be important for users of the current release +(or for a distribution picking fixes), it is usually a good candidate +for stable. + + +How to get a patch into QEMU stable +----------------------------------- + +There are various ways to get a patch into stable: + +* Preferred: Make sure that the stable maintainers are on copy when you send + the patch by adding + + .. code:: + + Cc: qemu-stable@nongnu.org + + to the patch description. By default, this will send a copy of the patch + to ``qemu-stable@nongnu.org`` if you use git send-email, which is where + patches that are stable candidates are tracked by the maintainers. + +* You can also reply to a patch and put ``qemu-stable@nongnu.org`` on copy + directly in your mail client if you think a previously submitted patch + should be considered for a stable release. + +* If a maintainer judges the patch appropriate for stable later on (or you + notify them), they will add the same line to the patch, meaning that + the stable maintainers will be on copy on the maintainer's pull request. + +* If you judge an already merged patch suitable for stable, send a mail + (preferably as a reply to the most recent patch submission) to + ``qemu-stable@nongnu.org`` along with ``qemu-devel@nongnu.org`` and + appropriate other people (like the patch author or the relevant maintainer) + on copy. + +Stable release process +---------------------- + +When the stable maintainers prepare a new stable release, they will prepare +a git branch with a release candidate and send the patches out to +``qemu-devel@nongnu.org`` for review. If any of your patches are included, +please verify that they look fine. You may also nominate other patches that +you think are suitable for inclusion. After review is complete (may involve +more release candidates), a new stable release is made available.
Some pointers on how to get a patch into stable. [contains some suggestions by mdroth] Signed-off-by: Cornelia Huck <cohuck@redhat.com> --- RFC/D->v2: added mdroth's suggestions --- docs/stable-process.rst | 67 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 docs/stable-process.rst