Daniel Shahaf wrote:
> Julian Foad wrote on Fri, 30 Aug 2019 06:54 +00:00:
>> Daniel Shahaf wrote:
>>> I think that section as it stands (before your change) is pretty hard to
>>> follow: it jumps back and forth between different topics. I might take
>>> a shot at clarifying it (without semantic changes), if that won't
>>> conflict with patches you have in flight.
>>
>> Yes please!
>>
>> I strongly urge that we simplify any and all of our documentation at any
>> opportunity. Nearly all of it is much too long. It would be much better
>> to state the facts in a few bullet points, and move the discussion of
>> rationale and history to a dedicated subsection so readers just wanting
>> the facts can easily skip that part.
>
> I've had a go, see staging/. Feel free to take it from here.
You've improved the information content and clarity. Thank you. We can
publish that as it is, even with the unresolved TODO about defining "veto".
I notice it's now ~32 lines longer, not counting section headers. I wish
we could somehow take out more than we add in.
>>> What do you propose to do about the rule that changes to tools/ or
>>> bindings/ require 1×+1 and 1×+0? It would be odd if changes to tools/
>>> required more votes than changes to core.
>>
>> Good catch. Should require just one +1 vote (removing the additional +0
>> vote).
>
> While editing on staging/ I noticed there was an explicit bit of
> rationale there about getting two pairs of eyes on every change.
> I guess you should change that part too (make it applicable to LTS
> lines only)?
Yes, that would be in accordance with the proposal.
> Or alternatively, require at least a +1 and a +0 on
> core changes to non-LTS lines.
I don't mind exactly what rules we end up with, just so long as it is
lighter weight than for LTS releases.
Thanks,
- Julian
Received on 2019-08-30 21:48:05 CEST