From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Like Xu <like.xu.linux@gmail.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] KVM: vmx, pmu: accept 0 for absent MSRs when host-initiated
Date: Thu, 16 Jun 2022 15:30:32 +0000 [thread overview]
Message-ID: <YqtMmAiOvJbmHCaP@google.com> (raw)
In-Reply-To: <69fac460-ff29-ca76-d9a8-d2529cf02fa2@redhat.com>
On Thu, Jun 16, 2022, Paolo Bonzini wrote:
> On 6/15/22 20:52, Sean Christopherson wrote:
> > I completely agree on needing better transparency for the lifecycle of patches
> > going through the KVM tree. First and foremost, there need to be formal, documented
> > rules for the "official" kvm/* branches, e.g. everything in kvm/queue passes ABC
> > tests, everything in kvm/next also passes XYZ tests. That would also be a good
> > place to document expectations, how things works, etc...
>
> Agreed. I think this is a more general problem with Linux development and I
> will propose this for maintainer summit.
I believe the documentation side of things is an acknowledged gap, people just need
to actually write the documentation, e.g. Boris and Thomas documented the tip-tree
under Documentation/process/maintainer-tip.rst and stubbed in maintainer-handbooks.rst.
As for patch lifecycle, I would love to have something like tip-bot (can we just
steal whatever scripts they use?) that explicitly calls out the branch, commit,
committer, date, etc... IMO that'd pair nicely with adding kvm/pending, as the
bot/script could provide updates when a patch is first added to kvm/pending, then
again when it got moved to kvm/queue or dropped because it was broken, etc...
next prev parent reply other threads:[~2022-06-16 15:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 17:54 [PATCH 0/2] KVM: vmx, pmu: respect KVM_GET_MSR_INDEX_LIST/KVM_SET_MSR contracts Paolo Bonzini
2022-05-31 17:54 ` [PATCH 1/2] KVM: vmx, pmu: accept 0 for absent MSRs when host-initiated Paolo Bonzini
2022-05-31 18:37 ` Sean Christopherson
2022-06-01 2:46 ` Like Xu
2022-06-01 8:50 ` Paolo Bonzini
2022-06-01 16:39 ` Sean Christopherson
2022-06-02 2:12 ` Like Xu
2022-06-15 18:52 ` Sean Christopherson
2022-06-16 10:37 ` Paolo Bonzini
2022-06-16 15:30 ` Sean Christopherson [this message]
2022-06-01 8:54 ` Paolo Bonzini
2022-06-01 9:12 ` Yang, Weijiang
2022-06-01 10:15 ` Paolo Bonzini
2022-06-01 10:42 ` Yang, Weijiang
2022-05-31 17:54 ` [PATCH 2/2] KVM: x86: always allow host-initiated writes to PMU MSRs Paolo Bonzini
2022-06-01 1:12 ` Like Xu
2022-06-08 22:22 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YqtMmAiOvJbmHCaP@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.