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

[Pete Batard]

Hi Leif,

On 2019.11.20 10:27, Leif Lindholm wrote:
> On Tue, Nov 19, 2019 at 04:30:05PM +0000, Pete Batard wrote:
>>> Please keep in mind that when open source maintainers take ownership
>>> of your code, they assume the responsibility to ensure that it doesn't
>>> get broken by future updates elsewhere in the codebase, often way
>>> beyond the commercial lifetime of the product that is supported by
>>> that code. This is a sizable effort, and an important part of managing
>>> that effort is ensuring that the code is in an acceptable shape to
>>> begin with, and what 'acceptable' means differs between different
>>> maintainers. Not being able to revert a patch easily because it
>>> touches unrelated code may make our lives more difficult years after
>>> you have stopped caring about this platform entirely.
>>
>> I think you are actually exposing the root of the problem without realizing
>> it here.
> 
> That is quite a condescending thing to say.
> 
>> Elements that may make a maintainer's life more difficult years after the
>> contributor stopped working on it can actually be elements that makes, and
>> will continue to make, a whole lot of developers' lives much easier right
>> now.
> 
> Much easier than occasionally using git add --patch or git-gui to
> stage individual hunks?
> 
> Splitting occasional minor changes out into separate patches should be
> < 1min effort.

That "should" *is* the exact issue.

That is the very core of what I am trying to raise here: additional time 
that is being incurred on contributors (as well as maintainers), which, 
I will continue to assert, if a project was less striving for academia 
excellence and more for the real life preservation of everyone's limited 
resources, it should be acceptable to spare when my own experience with 
both contributing and maintaining Open Source projects (yes, most of 
them not as large as EDK2, but also most of them not as small as a a 
single person's side project) has repeatedly demonstrated that 
flexibility rather than intractability with regards to rules, when they 
happen to save everybody's time, is one of the greatest factor in 
attracting quality contributions.

The root of the matter is that, more than often, I have found that what 
"should" be a <1 min effort, turns into a 15 mins or in the worst case 
up to a 1 hour endeavour due to side issues stepping in. And yes, that 
applies even to splitting the occasional minor changes for one-liner 
typos (and please don't be tempted to construe these as unfamiliarity 
with the tools being used), though I will agree that, in most cases, it 
*shouldn't* be that bad. But I will firmly dispute the idea that even 
the most straightforward typo fix effectively takes less than a minute 
to accomplish when you are considering the whole picture (rather than 
the amount of time one may effectively be spending invoking git commands).

Or are you under the impression that someone who is advocating for patch 
piggybacking is not concerned enough with the quality of what they 
submit, to actually want to validate that what they are splitting is up 
to good standards? Even for a one liner, ensuring that a split commit 
does comply to the expected standards of a project like EDK2 is more 
than a one minute affair. And everybody who has enough experience is 
familiar with a "Surely this simple one liner shouldn't break anything" 
that turned into a more dramatic affair than wanted. And yes, I am also 
considering the case where one would be doing the split from the get go 
rather than the one where one submitted a patchset and then a maintainer 
asked them to further split part of it.

Therefore, if you are thinking the earlier statement you pointed to 
above was condescending, then I'd like to present another contender for 
that prize. This <1 min effort is not the reality I have been observing, 
or the one I am expecting anyone else to be observing, which is what is 
actually prompting me to want to go over these matters.

Instead, I will assert that spending less than a minute splitting minor 
changes into a patch series is the exception rather than the rule for 
any contributor who does take the quality of what they submit seriously.

And that is the very core of the issue, because it then becomes a matter 
of having to deallocate time from other endeavours, which is what I 
would like to see at least acknowledged instead of being dismissed as a 
"non issue", because, IMO, this is a matter that I think Open Source 
project maintainers also need to keep on their radar.

>> For instance, someone today or tomorrow (rather than 2 or 5 years down the
>> line) can very well copy from code that got rejected as an "Also" (say, the
>> one instance I found in the Pi source where a %s was used instead of a %a,
>> which is an easy thing to miss if you're not paying attention) and find out
>> they are wasting time on an issue that they would never have had to contend
>> with, had the EDK2 maintainership been flexible with regards to what might
>> be acceptable to piggyback on a patch that pertains to a specific file (IMO,
>> fixing typos or style should always be acceptable as a piggyback, and I'd
>> really like to hear how including such changes is effectively going to make
>> the maintainers' job that harder down the line).
> 
> Ard gave a very specific example in the email you are replying to.

I believe Ard gave a conditional example of what he thinks may happen 
down the line.

I tried to counter with the idea that, if you try to look at the big 
picture, maybe the time possibly being spent that far down the line is 
going to be more than compensated by the time having already been saved 
by others.

> I can give (and have given) you others, but since those have seen no
> reaction (either acknowledgment or detraction) from you, there seems
> to be little point in adding more.
> 
>> And though this is a not directly related issue, I could also speak volumes
>> on how myself, and I assume many, many other developers, have wasted
>> countless hours (my current estimate puts that to around 4 to 5 hours in my
>> case) on the current CRLF enforcing situation with the EDK2 codebase.
> 
> That is a completely unrelated issue, which I have certainly also
> wasted spectacular amounts of time on.

I wouldn't say completely unrelated. Though I am of course not aware of 
the full specifics of it, which might justify some of the delayed action 
that is being taken. Instead, I was trying to use it as an example of a 
project seemingly deciding that it should be acceptable for contributors 
to collectively waste what I will assert is an exceedingly large amount 
of time, rather than just bite the bullet and state "We're gonna pause 
everything and take how many number of days we need to fix that now, so 
that our contributors stop having to waste hours on a matter that no 
other major Open Source project has to make them contend with".

Considering that you are happy to cite the Linux kernel as an example, 
let me posit the following: Do you believe that Linus would have just 
acknowledged that the CRLF issue as something that it is acceptable to 
fix years down the line and that contributors should just have to learn 
to accept for however long it may remain unaddressed?

And that is precisely my point: How far does a project see it as 
acceptable to push time wastage onto contributors, be it for having to 
contend with CRLF issues or spending an extra 5, 10, 15 minutes here and 
there (sometimes more) to split couple-liners into separate patches.

This, IMO, makes the CRLF matter related to this whole discussion. As a 
matter of fact, it is in part not seeing the matter of CRLF having been 
addressed a long time ago that lead me to worry enough about the 
direction this project wants to take to want to post about patch 
piggybacking for typos and style. Had EDK2 sorted CRLF, I probably would 
have kept this reflection to myself...

> And am working towards getting rid of.

That's good to hear. It genuinely can't happen fast enough as I've 
literally just wasted about another hour on this today...

>> All this to re-state that I wish there existed a balance between the well
>> established needs of the maintainers, and what they envision might emerge as
>> issues in the long run (which I assert tends to encourage them to preserve
>> an existing status-quo), and the possibly not so well publicized pain points
>> and time wastage that consumers of the codebase encounter, who, of course
>> (and, depending on how this discussion goes, I might come to see as perhaps
>> the wisest choice) generally tend to avoid venting their frustration on a
>> mailing list that aims at concerning itself solely with technical
>> discussions...
> 
> This isn't a balance discussion. Either you believe that open source
> development happens in changesets or you do not.

I'm just trying to share my experience, stemmed from participating in 
(as well as maintaining) multiple Open Source projects, some of which 
worked well and others which I would qualify as more dysfunctional, 
where I have found that intractability in changeset rules, and the 
inability of maintainers to acknowledge collective "time wastage" (by 
insisting that rules are not there to be flexible or even debated) 
eventually became a deterrent to attracting contributions and, in some 
case, resulted in the project being left struggling.

And please understand that I'm not pushing for maintainership to just 
accept whatever (for instance, I'm not going to state that a patch that 
contains 4 lines of effective code change and 4 of fixing typos/style, 
even super obvious one, should not be split). Just that there should be 
some form of balance with regards to how flexible patchset rules should 
be when one can expect that the collective amount of time wasted by both 
maintainership and contributorship can be reduced in the long run 
(which, in the absolute, may indeed very well incur additional time 
being spent by maintainership, but which, and this is my point, 
maintainership should understand is part of the collective effort to 
ensure that one of the prime resource they need to concern themselves 
with, i.e. the time that needs to be devoted to achieve a desired 
standard of code quality, is minimized for everyone rather than just a 
single party).

> Either you see the
> value in that for debugging, or you do not.
> 
> If what you care about is the ability to go back to what the tree
> looked like at a given point in time, then sure, a lot of this will
> seem very tedious to you.
> 
> This does not mean that any amount of debating the topic will convince
> anyone who relies on the fundamentality of changesets for their
> workflow.
> 
>> In other words, if you are willing to consider how much more painful
>> allowing the piggybacking of low-hanging "Also"'s onto existing patch may
>> make your life as a maintainer down the line, please also be willing to
>> envision the scenarios in which not allowing the same thing might actually
>> be making the life of people who work with the codebase, and I'd really like
>> to stress out that I'm really not talking only about myself here, harder
>> right now.
> 
> You do realise that apart from reviewing patches, we also write and
> contribute code ourselves - including to several other projects?
> All which follow the exact same rule.

Yes. And I am trying to make a point for the collective, which includes 
not just you, but everyone involved in the project.

> Suffice to say, this aspect of TianoCore is no more negotiable than
> the same aspect of linux, u-boot or QEMU.

Yes, that is entirely the choice of the maintainership of a project.

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.

Still I don't expect the project, or more exactly, individual attitudes 
with regards to what one sees as beneficial to the project, to change 
overnight, especially for a behemoth like EDK2. But I want to leave that 
point in the open so that people like you can at least reflect on it 
when they are confronted with various aspects of the project's life, 
which *may* eventually lead them to rethink, as it happened to me, 
whether *some* amount of flexibility can actually be more beneficial to 
a project than over reliance on intractable rules.

> I will be sorry to see you stop contributing to TianoCore if that is
> the effect,

I'm not planning to. As a matter of fact, some years ago, I might have 
made the same arguments you are making to dismiss my very own point, as 
it's only from participating in multiple projects that I have come to 
realize the importance of minimizing time wastage when it comes to 
keeping a project attractive. So I don't consider this discussion, 
regardless of its outcome, as something that would ever lead me to quit 
wanting to contribute to EDK2 altogether. And I also certainly hope that 
this discussion does not come across as as me berating maintainership of 
the project, which, when compared to other projects, I think is actually 
doing a very fine job overall (even if I may come to disagree with some 
the more minute aspects of what is for best when it comes to maintaining 
a project).

It will however limit my willingness to fix low-hanging fruits, as I 
can't recall instances where ones I've tried to fix in the past were the 
<1 min effort you talk about. Even the patch you sent where you 
effectively did the splitting ended up being a 10-15 mins job to 
integrate and resulted in me having to manually edit stuff. And that is 
not even taking into account the time incurred by having to rework the 
second patch in the series or work needed to get the repo to a state 
where said patch should have been applicable.

> but I am not willing to continue to rehash the very
> fundamentals of open source development.

Open Source is what we make it. I believe it is still new enough to 
still be trying to figure out the "rules" that work best. I certainly 
wouldn't say we have figured everything yet to be sure that some of the 
rules we currently apply don't warrant further tweaking...

Regards,

/Pete

PS: If folks start to think that discussion is becoming too distracting 
for the list, then I have no problem taking it off-list, tough I would 
assert that I've pretty much covered everything I wanted to expose with 
regards to my position at this stage.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50984): https://edk2.groups.io/g/devel/message/50984
Mute This Topic: https://groups.io/mt/57792459/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-