[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v20 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMA

From: Michael S. Tsirkin
Subject: Re: [PATCH v20 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)
Date: Tue, 3 Dec 2019 01:25:22 -0500

On Tue, Dec 03, 2019 at 07:00:53AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
> > On Tue, Dec 03, 2019 at 08:53:30AM +0800, Tao Xu wrote:
> >> Hi Michael,
> >> 
> >> Could this patch series be queued?
> >> Thank you very much!
> >> 
> >> Tao
> >
> > QEMU is in freeze, so not yet. Please ping after the release.
> Just to avoid confusion: it's Michael's personal preference not to
> process patches for the next version during freeze.  Other maintainers
> do, and that's actually the project's policy:
> Subject: QEMU Summit 2017: minutes
> Message-ID: <address@hidden>
> https://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg04453.html
>     qemu-next:
>      * Problem 1: Contributors cannot get patches merged during freeze
>        (bad experience)
>      [...]
>      * Markus Armbruster: Problem 1 is solved if maintainers keep their own
>        -next trees
>      * Paolo Bonzini: Maintaining -next could slow down or create work for
>        -freeze (e.g. who does backports)
>      * Action: Maintainers mustn't tell submitters to go away just because
>        we're in a release freeze (it's up to them whether they prefer to
>        maintain a "-next" tree for their subsystem with patches queued for
>        the following release, or track which patches they've accepted
>        some other way)
>      * We're not going to have an official project-wide "-next" tree, though
> Michael, would queuing up patches in a -next branch really be too much
> trouble for you?

Thanks for pointing this out!

I stopped asking for re-post since awhile ago.  I don't queue patches in
a public tree but I do review and do keep track of pending patches.

I tend to ask contributors to also ping because sometimes there's a
problem with rebase, I drop the patch but forget to tell the
contributor, and it tends to happen more with big patchsets posted during
freeze as there's a rush to merge changes right after that.
I usually don't bother people with this for small patches though.

I'll try to be clearer in my communication so contributors don't feel

Would something like:

"I'll queue it for merge after the release. If possible please ping me
after the release to help make sure it didn't get dropped."

be clearer?

Hopefully windows CI efforts will soon bear fruit to the point where
they stress PCI enough to make maintaining next worth the effort.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]