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

["Leif Lindholm" <leif.lindholm@linaro.org>]

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.

> 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 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. And am working towards getting
rid of.

> 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. 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.

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

I will be sorry to see you stop contributing to TianoCore if that is
the effect, but I am not willing to continue to rehash the very
fundamentals of open source development.

/

    Leif