Quoting Peter Maydell (2016-10-17 12:33:18) > On 17 October 2016 at 17:51, Michael Roth <mdr...@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 >