Message-ID: <32ed59c9-c894-c426-dd27-3602625cf3b1@netscape.net>
Date:   Sun, 14 Aug 2022 03:42:20 -0400
From:   Chuck Zmudzinski <brchuckz@...scape.net>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     jbeulich@...e.com, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Pavel Machek <pavel@....cz>, Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        regressions@...ts.linux.dev, Juergen Gross <jgross@...e.com>,
        xen-devel@...ts.xenproject.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: make pat and mtrr independent from each other

On 8/13/2022 12:56 PM, Chuck Zmudzinski wrote:
> On 7/17/22 3:55 AM, Thorsten Leemhuis wrote:
> > Hi Juergen!
> >
> > On 15.07.22 16:25, Juergen Gross wrote: ...
>
> Hi Thorsten,
>
> This appears stalled again and we are now over three months
> from the first report of the regression, The only excuse for
> ignoring your comments, and other comments on the patches
> in this patch series for this long a time is that the patch series
> for some reason cannot be considered a true regression. If this is a
> regression, then, IMHO, this needs to have a higher priority by the
> maintainers, or the maintainers need to explain why this regression
> cannot be fixed in a more timely manner. But continued silence
> by the maintainers is unacceptable, IMHO. This is especially true
> in this case when multiple fixes for the regression have been
> identified and the maintainers have not yet clearly explained why
> at least a fix, even if temporary, cannot be applied immediately
> while we wait for a more comprehensive fix.
>
> At the very least, I would expect Juergen to reply here and say that
> he is delayed but does plan to spin up an updated version and include
> the necessary links in the new version to facilitate your tracking of
> the regression. Why the silence from Juergen here?

This is a fairly long message but I think what I need to say
here is important for the future success of Linux and open
source software, so here goes....

Update: I accept Boris Petkov's response to me yesterday as reasonable
and acceptable if within two weeks he at least explains on the public
mailing lists how he and Juergen have privately agreed to fix this regression
"soon" if he does not actually fix the regression by then with a commit,
patch set, or merge. The two-week time frame is from here:

https://www.kernel.org/doc/html/latest/process/handling-regressions.html

where developers and maintainers are exhorted as follows: "Try to fix
regressions quickly once the culprit has been identified; fixes for most
regressions should be merged within two weeks, but some need to be
resolved within two or three days."

I also think there is a private agreement between Juergen and Boris to
fix this regression because AFAICT there is no evidence in the public
mailing lists that such an agreement has been reached, yet Boris yesterday
told me on the public mailing lists in this thread to be "patient" and that
"we will fix this soon." Unless I am missing something, and I hope I am,
the only way that a fix could be coming "soon" would be to presume
that Juergen and Boris have agreed to a fix for the regression in private.

However, AFAICT, keeping their solution private would be a violation of
netiquette as described here:

https://people.kernel.org/tglx/notes-about-netiquette

where a whole section is devoted to the importance of keeping the
discussion of changes to the kernel in public, with private discussions
being a violation of the netiquette that governs the discussions that
take place between persons interested in the Linux kernel project and
other open source projects.

Yet, in one of his messages to me yesterday, Boris appended the link
to the netiquette rules, thus implicitly accusing me of violating the
netiquette rules when in fact he is the one who at least seems to be
violating the rule forbidding private discussions of changes to the
kernel once a patch set is already up for discussion on the public
mailing lists.

Of course Boris can exonerate himself completely if within two
weeks he at least explains on the public mailing lists how he and
Juergen have agreed to fix the regression. I sincerely hope he at
least does that within the next two weeks, or even better, that he
exonerates himself by actually committing the official fix for the
regression within the next two weeks.

However, I will only believe it when I see it. When it comes to the
Linux kernel, I go by what I see  in the performance of the Linux
kernel in my computing environments, what I see on the public
mailing lists and in the official documentation, and by what I
see in the source code itself. I do not go by blind faith in any
single developer. I am not religious when it comes to the Linux
kernel. Instead, I am scientific and practical about it.

Finally, please forgive me also if I am mistaken in my assumption
that these rules of netiquette apply no less to the developers and
maintainers of the Linux kernel than to others who wish to offer
their contributions to the development of the Linux kernel. If the
rules of netiquette do not apply to the developers and maintainers,
of the kernel, then, IMHO, the great advantage of open source
software development is totally lost, because the advantage of the
open source software development model depends at least as
much on free and open access to the discussions about the
source code conducted by the developers and maintainers as it
does on the freedom to have access to the source code itself.
If someone here tells me that those rules of netiquette need
not be followed by the developers and maintainers I certainly
hope someone else will come to the defense of those same
wise rules that have allowed such a successful open source
software ecosystem to flourish and thrive around this project,
the Linux kernel.

IMHO, the day someone make the decision to stop enforcing these
wise rules is the day that the open source development model will
begin to lose its advantage over proprietary software development
models. And perhaps the most important rule of all for the continued
success of Linux and open source software development is the Linus
regression rule, with the rule that discussions about changes
to the source code must be done in public being a close second in
importance to the Linus regression rule.

Best Regards,

Chuck

Powered by blists - more mailing lists