Re: [edk2-devel] more development process failure [was: UefiPayloadPkg: Runtime MMCONF]

["Laszlo Ersek" <lersek@redhat.com>]

On 09/17/20 09:31, Yao, Jiewen wrote:
> Laszlo
> I like your description to compare the process with the programming language and software design. We have to clean up the resource.
> 
> Please allow me to point out, this is the exactly the issue we are having today.
> 
> 1) Take buffer overflow as an example. It has been there for 30 years. We have enough books and papers talking about it. Today, people are still making mistakes. Why? Because C language is not type safe, there is NO enforcement.
> That is why many people like other type safe language. If you are trying to make mistake, the compiler will tell you that you are making mistake.

This will sound more convincing once we have Rust (or something similar)
in a mainstream OS kernel or mainstream firmware.

> 2) Take resource leak as an example. The programming language invented garbage collection. The operating system auto cleaned up application resource after execution.

Same comment as above. I think garbage collection is frequently
considered too opaque for low-level applications (unpredictable
performance and RAM penalties etc).

> 3) People has wrong check in which may break the system. What is why the world invented smoke test and continuous integration.

Yes, I agree.

> *Those are where the inventions come*, to treat human as human being, to prevent people making mistake or teach them automatically. :-)

Thanks, I'm grateful that you use the word "teach" here. I'll reference
it below.

> I agree with the "mythical man-month" that there is no silver bulletin.
> I tend to agree with you on the attitude.
> I am trying to figure if we can do better to help other people (maintainer or contributor). If we really really can do nothing, that is OK.
> I am not sure if is a best way to resolve the problem to just complain in the email.

"Just complaining in email" is in fact my attempt to "teach" people. Not
automatically, but by pointing out examples that I consider good.

Automatisms are already in place for broadcasting good practices.
Bugzilla actions and github actions are propagated via email. People
just need to be receptive and look at the list traffic.

I've contributed to Wiki articles. But asking for more documentation and
more automatisms is just too convenient an excuse. People can and
*should* learn by example, especially if they're seasoned in a project
(not newcomers). Asking for more documentation and more automatisms puts
the burden on people *different* from those that need to improve their
discipline.

It basically means, "I refuse to improve my behavior until *you* find
the time to implement the tools and documentations for me to improve my
behavior". Similarly, "I refuse to handle errors until you give me
exceptions and destructors".

I don't think it's fair to *demand* inventions. Because, I perceive the
goals that I'm advocating for as widely-held values. If we accept them
as such, then the burden should be on people that break those values,
not on the advocates.

(If, on the other hand, we do not have a consensus that these values are
universal, that's OK as well: then I can start ignoring the information
content in the PRs that *I* submit, and save myself significant amounts
of time. See again: double standards.)

> I think you can understand my point. I will stop here.

Yes, I understand. My general response is that inventions are nice and
they should be utilized if someone comes forward and offers them. On the
other hand, demanding inventions (tooling, documentation etc), i.e.,
demanding that the *other* party spend the effort first, as a condition
for changing our attitude, is not fair.

Laszlo