Re: [edk2-devel] [edk2-platforms][PATCH 1/8] Platform/RPi: Add model family detection

["Pete Batard" <pete@akeo.ie>]

Hi Laszlo,

I appreciate your input on this.

However, I find it unfortunate that you seem to be equating my concern 
about minimizing time wastage to "moving fast", as those are two very 
different matters, and "moving fast" isn't what I have been trying to 
advocate for at all.

None of the points I tried to raise are borne from what you might 
perhaps have perceived as a contributor's frustration about a project 
not moving fast enough in their eye. Especially, considering that I've 
literally had to deal with Open Source projects where integration of 
some patches became a multi-year affair (and where this extended delay 
had nothing to do with the usual review/rework/resubmit process) then I 
have to state that there is little to be frustrated about when it comes 
to how fast one is able to get things reviewed and integrated in the EDK2.

Yet, one can move fast or slow, and still waste time.

I guess if I wanted to address some of the points you raise, I could 
mention that lack of flexibility with regards to some rules can come as 
a deterrent to contributors, especially new ones if they have to spend 
what they perceive as an unwarranted amount of their time on elements 
that they'll be hard pressed to see actual tangible benefits of for the 
project as a whole, and how this may ultimately play into contributors 
not wanting to stick around (with the end result of increased work and 
wasted time for maintainers).

But I feel like I would mostly be a re-hashing of what I have already 
tried to point out. Therefore, with the clarification above having been 
made, I am planning to leave the matter at that.

Regards,

/Pete

On 2019.11.21 09:04, Laszlo Ersek wrote:
> On 11/21/19 09:55, Laszlo Ersek wrote:
>> On 11/20/19 22:50, Pete Batard wrote:
>>
>>> [...]
>>>
>>> Which is why I am trying to invite them to consider one aspect that I
>>> believe is often overlooked: trying to treat time as the 3d most
>>> valuable resource a project needs to concern itself with (end-user
>>> experience being first and overall code/software quality second), and
>>> applying flexibility to what some might be a bit too eager to treat as
>>> non-negotiable rules as a result of that. Rules should be made to serve
>>> and foster those resources rather than the opposite.
>>
>> Contribution rules are already made to prioritize time and effort --
>> *maintainer* time and effort.
>>
>> - There are fewer maintainers than contributors.
>>
>> - Maintainers tend to stick around for long, contributors may or may not
>> (it varies).
>>
>> - Maintainers generally take more responsibility for the codebase, as a
>> whole, than contributors do.
>>
>> - In most cases, reading code is more difficult than writing code.
>>
>> All of the above turn maintainership and patch review into a permanent
>> bottleneck at the project level. Unclogging that bottleneck is what
>> project rules prioritize.
>>
>> Nobody doubts that strict contribution rules create bottlenecks on the
>> contributor side. That's the lesser wrong. "Moving fast" leads to
>> regressions. In a halfway mature project, which users have grown to rely
>> on, regressions destroy end-user experience (which you put as first
>> priority).
> 
> BTW I don't claim that "strict rules" are the only way to keep
> regressions out.
> 
> Many projects that "move fast" justify moving fast, and justify easing
> up on patch review, with having thorough CI. "Thorough CI" is also not
> easy though (in particular integration tests) -- keeping the test suite
> up-to-date, reviewing patches for the tests (incl. test infrastructure),
> plus operating the test environment, also require time and effort.
> 
> Thanks
> Laszlo
>