Re: [PULL 00/15] riscv-to-apply queue

[Michael Tokarev]

26.03.2024 12:56, Alistair Francis пишет:
> On Tue, Mar 26, 2024 at 7:53 PM Michael Tokarev <mjt@tls.msk.ru> wrote:
> > On 24.03.2024 21:12, Daniel Henrique Barboza wrote:
> > > On 3/24/24 12:07, Michael Tokarev wrote:
> >
> > > > Unfortunately this doesn't quite work, the following changes
> > > > fail to apply to 8.2:
> > > >
> > > > 929e521a47 target/riscv: always clear vstart for ldst_whole insns
> > > > b46631f122 target/riscv: remove 'over' brconds from vector trans
> > > > d57dfe4b37 trans_rvv.c.inc: remove redundant mark_vs_dirty() calls
> > > > bac802ada8 target/riscv: enable 'vstart_eq_zero' in the end of insns
> > > > 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration
> >
> > > The amount of work can be non-trivial for this backport, so I'd say we should
> > > leave it aside for now. If someone has a good argument for this work then we
> > > can re-evaluate.
> >
> > So, out of 15 patches in this series (minus the first one already
> > mentioned) - should I pick 9 remaining patches for stable (the ones
> > which applies) or none at all? :)
>
> Sorry for the confusion.
>
> The 9 patches that applied and
>
> 385e575cd5 target/riscv/kvm: fix timebase-frequency when using KVM acceleration
>
> should all be picked for stable.

Got it, picked all plus 385e575cd5 which needed just trivial context fixup.
Thank you for the clarification!

> PS: What is the best way in future to help ease some of the stable
> burden? Should I try and cherry pick them beforehand and then mention
> that as a follow up to the PR?

The only problem for me so far is the patch selection, - this is why I'm
asking to Cc changes which should go to stable, to qemu-stable@.  So far
I was a bit pro-active and asked about some changes which I *feel* are
suitable, like in this case.  It is much better if someone who actually
has knowledge about the area being changed, decides if it's stable material
or not.  At the same time, I don't mind at all if more changes than needed
are Cc'ed like this, - at least as long as it's obvious they're not really
needed (like fixing a bug introduced in commit which isn't in any release
yet).

I usually don't have any issues with applying patches which don't apply
directly to stable - this is not a burden.  In some cases when this happens,
I can edit the commit (like I just did for 385e575cd5), or pick some previous
changes too if they're okay, or in even more rare cases, ask for clarification
or even for help with back-porting, - but this last category is really rare.

Some changes gets rejected for stable in the end due to too much back-porting
effort or requiring too much prior context.

So the only real issue for me is to know which changes are to pick, - that's 
all.
And this is the only thing I'm asking, - in this thread and elsewhere.

Thank you!

/mjt