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

[Michael Roth]

Quoting Thomas Huth (2016-10-17 02:44:59)
> On 14.10.2016 19:38, Peter Maydell wrote:
> > On 14 October 2016 at 09:27, Greg Kurz <address@hidden> wrote:
> >> On Fri, 14 Oct 2016 09:28:35 +1100
> >> David Gibson <address@hidden> wrote:
> >>
> >>> On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
> >>>> On 13 October 2016 at 12:54, Peter Maydell <address@hidden> wrote:
> >>>> More generally, we need to come up with something for distinguishing
> >>>> PULL requests not for master, because my current workflow basically
> >>>> says "anything that says 'for you to fetch changes up to' will get
> >>>> merged into master...
> >>>
> >>> Um.. yes.. this was intended for merge to the 2.7 branch, not master.
> >>> Any ideas how I should express that?
> >>>
> >>
> >> I'm not aware of any formal process, other than sending a mail to
> >> qemu-stable and Cc: Michael Roth. This is often done by simply
> >> replying to selected messages in the pull requests for the master
> >> branch.
> >>
> >> Then Michael does all the cherry picking stuff and usually sends a
> >> patch round-up two weeks before the stable release, for people to
> >> review.
> > 
> > Yes, I think I was partly thrown because in general patches
> > don't go into the stable branches via pull requests.
> > That said, my current filter/workflow is clearly broken
> > so I'm open to any suggestions for easy-for-me-to-filter-for
> > ways to flag up that a pull request isn't aimed at master.
> 
> Maybe simply filter out the requests that include qemu-stable in "To:" ?

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.

> 
>  Thomas
> 
>