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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#51111): https://edk2.groups.io/g/devel/message/51111
Mute This Topic: https://groups.io/mt/57792459/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
