On Thu, Aug 8, 2024, at 9:10 AM, Andreas Heigl wrote:
> Hey Gina, hey all
>
> Am 08.08.24 um 15:44 schrieb Gina P. Banyard:
>> On Wednesday, 7 August 2024 at 17:07, Andreas Heigl <[email protected]>
>> wrote:
>>> Stupid question maybe, but are we voting on the RFC or on the patch?
>>>
>>> If the patch does not match what.the RFC proposes, then the patch has
>>> a problem. That should IMO though not affect voting on an RFC.
>>>
>>> Or am I.missimg something?
>>
>> In theory, it is the RFC idea.
>> In practice, a lot of the times it is the patch for complex features.
>>
>> However, it is still within the purview of core developers to veto the
>> implementation of an RFC.
>> Which could be the case here rather than voting against the RFC outright.
>
> I have no problem that core developers veto a certain implementation of
> an RFC. I actually expect them to do so.
>
> But the vote should IMO *always and exclusively* be based on the RFC.
> Not on the implementation. If the voting happens based on the
> implementation due to the complexity of the features that means that the
> RFC is not wel written and needs to be improved. Or the implementation
> is problematic and needs to be vetoed by the core developers.
How exactly would voters veto an implementation if not through the RFC? That's literally the
only formal input mechanism they have, and previous attempts to add others have been soundly
rejected.
As a historical note, the partial function application RFC was declined despite there being general
consensus that the proposal was quite good and quite desireable. The issue was that Nikita felt the
implementation proposed with it was too fragile, and wasn't sure how to make it less fragile,
so he voted No and several others followed suit. I am fairly confident that if a less-fragile
implementation could be found, it would pass handily.
So yes, RFCs have been rejected in the past on "implementation only."
--Larry Garfield