Re: [PATCH v6 0/3] ppc/e500: Add support for eSDHC

[Philippe Mathieu-Daudé]

On 3/11/22 16:13, Daniel Henrique Barboza wrote:
> On 11/3/22 09:51, BALATON Zoltan wrote:
> > On Wed, 2 Nov 2022, Daniel Henrique Barboza wrote:

> > > Queued in gitlab.com/danielhb/qemu/tree/ppc-8.0 (since we missed the
> > > freeze for 7.2).
> >
> > Could you please always use ppc-next to queue patches for the next 
> > upcoming version and ppc-7.2 for the current version? Unless this 
> > makes your workflow harder in which case ignore this but the reason I 
> > ask is because then it's enough for me to only track ppc-next if I 
> > need to rebase patches on that and don't have to add a new branch at 
> > every release (unless I have some patches to rebase on it during a 
> > freeze but that's less likely than rebasing on your queued patches for 
> > the next release xo using version for the current branch and keep next 
> > for the future versions makes more sense to me).
>
> Note that doing "ppc-7.2" for the current release and ppc-next for the
> next release will not prevent you from adding a new branch at every
> release, e.g. for the next release you would need to add a ppc-8.0
> branch.
>
> 'ppc-next' is used like a standard, a way of telling 'this is the next
> pull request that is going upstream'. Can we change it? Sure, but if the
> idea is to avoid new branches every new release then I suggest the
> following:
>
> - ppc-next: keep it as is

FWIW I use mips-next the same way,

> - ppc-next-release/ppc-future: branch that will host any code for the next
> release during the code freeze window. Note that this branch will become
> 'ppc-next' when the new release cycle begins

and use mips-fixes during freeze. My 2 cents, not sure it helps Zoltan.

> This would avoid changing everyone's workflow with the current ppc-next
> usage, while also standardize a branch for the future release patches
> during freeze.