Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth <mdroth@linux.vnet.ibm.com>]

Quoting Peter Maydell (2016-10-17 12:33:18)
> On 17 October 2016 at 17:51, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > Maybe just a tag like [PULL for-stable], or [PULL for-2.7]?
> >
> > The latter seems to mirror how we handle things for patches coming for
> > master during freeze. Others who've submitted patches they've
> > backported themselves for stable seem to naturally lean toward that
> > approach as well.
> >
> > That said, this might get confusing immediately after a release, where
> > there are a lot of patches floating around with such tags, cc:'d for
> > stable, that aren't actually meant to be directly pulled into stable.
> > So I think I would lean toward "for-stable", or, even better,
> > "for-2.7.1", etc.
> >
> > I don't do automated pulls so it's not a huge deal either way for me,
> > but "for-x" in general should hopefully be enough for Peter to filter
> > them out for master based on what whether "x" references the next
> > major release or not.
> 
> I don't really want to have to update my email filters every
> time we do a release, though, and so "for-X.Y" doesn't work because
> when we are in the runup to release pull requests targeting
> master tend to be marked that way.

What about just for-stable, for-stable-2.7, for-ppc-2.8, etc.?
Basically just adopt the for-* prefix for these sorts of pulls,
but reserve the for-x.y prefix for master, so that anything
that doesn't match for-\d\.\d can get filtered out based on
that single rule?

> 
> Maybe just having not-for-master pull requests say "not for master"
> in the cover letter somewhere ?

I tend to treat PULLs cc'd for stable as just having individual patches
marked for stable, so it's a bit easier to miss if it's not something
obvious like a subject line tag. 

It also kind of leaves it as an exercise for the reader what branch
other than master is actually the intended target for stuff like
sub-maintainer pulls (where there might actually be a bit more
automation).

We could do both though: use some ad-hoc way to tag for a particular
sub-maintainer tree/stable branch, as well as an explicit "not for
master" in the cover letter ensure it doesn't go into master. It's a bit
more redundant, but flexible in that people can use whatever tagging
format they want for a particular tree.

> 
> thanks
> -- PMM
>