areusch commented on PR #95:
URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285017979
thanks for the replies here, everyone.
@comaniac
>-1 is totally fine and I don't think this Process RFC forbids this. On the
other hand, if an RFC is suspensive for a while but we still cannot make every
-1 voter happy, it doesn't make sense to me to reject the RFC (we don't
actually "reject" it, but prevent it from merging forever is basically the same
as reject).
I guess my point here though is: we have this problem for PRs too. We trust
committers and PMC members not to blockade PRs so long as everyone is
collaborating. For ordinary RFCs, we have the same situation. We achieve lazy
consensus through discussion. In cases where there is a disagreement that
cannot be resolved, and the argument has run its course, I agree it may become
necessary to relax the requirement of lazy consensus in the name of progress. I
am not aware of such a case in the project right now.
To be explicit: in the case of the [Relax
RFC](https://github.com/apache/tvm-rfcs/pull/89), the authors have not answered
some key questions that contribute to "discussions about how the proposal fits
into the project." My understanding is that those answers are coming so the
argument is not deadlocked.
@sunggg
> Are you suggesting the consensus is the right way to go for this optional
module? If so, I'm wondering how you define the consensus. IMHO, reaching
unanimous might be practically impossible for the large community like this
Sorry--to clarify my original post, I am suggesting we adopt the same voting
mechanism as we do for PRs and ordinary RFCs.
> it does not seem to fit for S0: by definition, S0 is to satisfy clear
needs from some users in the community, not the entire users. I'm afraid if too
high bar for optional module may discourage contributors.
It seems like 3 PMC approvers is a higher bar for newcomers than merely
getting a +1 from a committer.
> This quote below sounds more about the standard process of how we digest a
giant commit, which could be orthogonal to voting rules.
This was meant to serve as an example of the effect of adopting a resolution
such as replacing the implementation of a large component or adopting a
submodule could wind up impacting the project in ways that materially determine
its future. It is common for projects to fork when two different factions
cannot reach consensus on a change of this magnitude. In such cases, I could
see the need to relax the consensus requirement in order to decide which way
the original project will go.
By contrast, an S0 proposal clearly limits its blast radius and should not
impact a project to the degree of forking. I don't see a clear reason why we
cannot use the same voting mechanism we do for PRs and RFCs here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
