RE: [RFC] Process to request a vote for an issue

[Cornelia Huck <cohuck@redhat.com>]

On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:

>> From: Cornelia Huck <cohuck@redhat.com>
>> Sent: Tuesday, May 28, 2024 7:39 PM
>> 
>> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
>> 
>> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> Sent: Tuesday, May 28, 2024 7:00 PM
>> >>
>> >> On Tue, May 28 2024, Parav Pandit <parav@nvidia.com> wrote:
>> >>
>> >> >> From: Cornelia Huck <cohuck@redhat.com>
>> >> >> Sent: Tuesday, May 28, 2024 6:21 PM
>> 
>> >> >> The last step currently mostly happens in the thread for the
>> >> >> latest revision; such an email is easily missed if you're not
>> >> >> actively following the
>> >> discussion.
>> >> >> IMHO it isn't a very reasonable expectation for the chairs to
>> >> >> follow each and every discussion in detail; at some point, it is
>> >> >> much more reasonable to expect trusted reviewers and SMEs to reach a
>> consensus.
>> 
>> Let's go back to the rationale here: Chairs should be able to find out easily
>> which issues they should open a vote on. This involves trusting that things
>> have been found reasonable by people familiar with the topic.
>> 
> Sure, however this solely is the request of the submitter to decide to ask for the vote.
> If things are not acceptable, anyway vote wont progress.
>
>> >> >>
>> >> >> Therefore, I propose that
>> >> >> - request for votes be posted in a new, separate thread, referring to
>> >> >>   the version proposed for inclusion and
>> >> > This looks good.
>> >> >
>> >> >> ideally containing a note on
>> >> >>   who deems this proposal ready for inclusion,
>> >> > This additional overhead does not seem necessary because when you
>> >> > pull
>> >> the patches using b4 tool.
>> >> > It automatically captures who has reviewed, acked those patches
>> >> > like any
>> >> other email based flow.
>> >>
>> >> I disagree: This only captures people giving their R-b or A-b; not
>> >> e.g. a SME saying "the hardware modeling looks good to me". A R-b
>> >> from a trusted virtio reviewer is obviously a good indication that
>> >> this is fine from a virtio perspective, but there's no way for Chairs
>> >> to know each and every SME and judging how valuable the R-b or A-b of
>> >> a person they do not know is. Just spell it out; "SME xyz says it
>> >> looks good" is a reasonable statement to indicate readiness for a vote.
>> >>
>> > You are trying to define two things in this one process.
>> > a. define process
>> > b. defining SMEs
>> >
>> > doing #b in this process does not look right to me.
>> > I wouldn't call it SMEs given that what you wrote above that "no way for
>> chairs to know each and every SME"..
>> > It is hard for non_chair to judge a person as SME or not. Seems broken there.
>> > Rather to keep things neutral and simple, why not just say, reviewed by or
>> acked by person xyz?
>> 
>> Again, it's not about "defining SME", I have no idea where you got this from. 
> Because you wrote the SMEs to write R-B or acked by.
>
>> I
>> just want the submitter to say "please open a vote for this,
>> $PERSON_WORKING_ON_VIRTIO and $PERSON who knows the backend are
>> happy with it." Nothing complicated, just an indication that it is reasonable to
>> open a ballot, trusting the submitter that they did any needed reviewing
>> cycles, and trusting that the people who said that it looks good did their due
>> diligence, and know what they are talking about. (Obviously, that's primarily
>> for more complex changes that touch areas that not everyone is familiar with,
>> a simple patch with an R-b does not need elaborate justifications; just use
>> some judgement.)
>
> Right. No need to attribute a person as SME or anything else.
> Person abc signed-off and person xyx reviewed/acked.
> Each information is present in last patch_N.
> Submitter to just copy paste that again in the new request vote email.
>
> TC already has voting committee to decide what to approve or not.
> Virtio TC has consciously not added any formal or informal sub-committees from last year of any intermediate SMEs.
> So, let's not complicate it now either.
>
> To your point, "Chairs should be able to find out easily which issues they should open a vote on"
>
> For any issue for which a diligent person has iterated the patches should have the right to ask for vote like today.
> Virtio TC has the ability to evaluate it and vote.
>
> If we need to discuss this more, than,
>
> Defining "process to request a vote" seems like a committee work to happen on the OASIS-virtio@ConnectedCommunity.org mailing list.
> Is virtio OASIS list still broken for you, hence discussion on this list?

Well, see my lead-in on the initial mail -- yes, it is broken (and not
just for me.)

>
> While defining the new things is good, a humble request is, lot of patches are currently in waiting stage for several weeks to months now.
> Starting with Heng's v5... and many of my patches.
> To be clear, we don't want to wait for the new process to slow down the snail further.
>
> The new steps you mentioned are good to start as long as it is not blocking patches already in the pipe.

Again, see my lead-in on the initial mail. (If things don't move once
we're good again, it's not intentional; just ping in that case.)

I'm waiting for feedback from others as well.