Re: [PATCH v2] Introduce a description of a new optional tag for Backports

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 14 Apr 2020, Jan Beulich wrote:
> On 10.04.2020 18:49, Stefano Stabellini wrote:
> > Create a new document under docs/process to describe our special tags.
> > For now, only add the new backport tag.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> > Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> > Acked-by: Wei Liu <wl@xxxxxxx>
> > CC: jbeulich@xxxxxxxx
> > CC: george.dunlap@xxxxxxxxxx
> > CC: julien@xxxxxxx
> > CC: lars.kurth@xxxxxxxxxx
> > CC: andrew.cooper3@xxxxxxxxxx
> > CC: konrad.wilk@xxxxxxxxxx
> > 
> > ---
> > 
> > This is the original thread: 
> > https://marc.info/?l=xen-devel&m=157324027614941
> > 
> > The backport tag was agreed upon.
> 
> Well, sort of.
> 
> > George requested the file to be
> > renamed to something more generic, where we could add more information
> > later.
> > 
> > I kept the original content and acked-by. I renamed the file to
> > tags.pandoc.
> > ---
> >  docs/process/tags.pandoc | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 docs/process/tags.pandoc
> > 
> > diff --git a/docs/process/tags.pandoc b/docs/process/tags.pandoc
> > new file mode 100644
> > index 0000000000..e570efdcc8
> > --- /dev/null
> > +++ b/docs/process/tags.pandoc
> > @@ -0,0 +1,23 @@
> > +Backport Tag
> > +------------
> > +
> > +A backport tag is an optional tag in the commit message to request a
> > +given commit to be backported to the stable trees:
> 
> Insert "fully maintained"?

Yep I'll add.


> > +    Backport: all
> > +
> > +It marks a commit for being a candidate for backports to all relevant
> > +trees.
> 
> I'm unconvinced of the utility of this form - what "all" resolves to
> changes over time. There's almost always a first version where a
> particular issue was introduced. If we want this to be generally
> useful, imo we shouldn't limit the scope of the tag to the upstream
> maintained stable trees.

The reason why I suggested also to have a "wildcard" version of this
tag, is that the person adding the tag (could be the contributor trying
to be helpful) might not know exactly to which stable trees the patch
should be backported to.

Writing this sentence, I realize that I really meant "any" rather than
"all". Would you prefer if I used "any"? Or we could even suggest to leave
it black like this:

  Backport:

But it looks a bit weird.


> > +    Backport: 4.9+
> > +
> > +It marks a commit for being a candidate for backports to all stable
> > +trees from 4.9 onward.
> > +
> > +Maintainers request the Backport tag to be added on commit.
> > +Contributors are also welcome to mark their patches with the Backport
> > +tag when they deem appropriate. Maintainers will request for it to be
> > +removed when that is not the case.
> > +
> > +Please note that the Backport tag is a **request** for backport, which
> > +will still need to be evaluated by the stable tree maintainers.
> 
> Now that we see more widespread use of the Fixes: tag, with there
> being effectively some overlap between the information conveyed I
> think there should be some mention of this. Not the least there's the
> risk of the Backport: one to become stale when a flaky commit gets
> backported - the Fixes: tag doesn't have this issue.

Yes, that's true, but "Fixes" cannot always be used. I can add a
statement like: "When possible use the Fixes tag."

Also, I can pull in the description of Fixes and add it to this file
too.


Fixes tag
---------

If your patch fixes a bug in a specific commit, e.g. you found an issue using
``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
the SHA-1 ID, and the one line summary.  Do not split the tag across multiple
lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify
parsing scripts.  For example::

        Fixes: 41548c5472a "mem_sharing: VM forking"

The following ``git config`` settings can be used to add a pretty format for
outputting the above style in the ``git log`` or ``git show`` commands::

        [core]
                abbrev = 12
        [pretty]
                fixes = Fixes: %h (\"%s\")