lkml.org 
[lkml]   [2022]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/3] x86: make pat and mtrr independent from each other
From
On 8/14/2022 3:42 AM, Chuck Zmudzinski wrote:
> 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

Hi Thorsten,

Well, that did not take long. Juergen responded with a message,
which is encrypted and not delivered to my mailbox because I do not
have the PGP keys, presumably to make it difficult for me to continue
the discussion and defend myself after I was accused of violating
the netiquette rules yesterday by Boris:

https://lore.kernel.org/lkml/c88ea08c-a9d5-ef6a-333a-db9e00c6da6f@suse.com/raw

Fortunately, lore.kernel.org did decrypt Juergen's message so you can read
what he wrote in response to my message there. I don't think what Juergen said
there is very constructive although I am not surprised he seeks to defend himself,
and he makes many valid points that are good for developers and Linux insiders
but not so good for users and the long-term success of the Linux kernel project,
so I am not going to reproduce what he said in this message, but I think you
need to read it to help you understand why this regression is not being fixed
in a timely manner:

https://lore.kernel.org/lkml/c88ea08c-a9d5-ef6a-333a-db9e00c6da6f@suse.com/

Sorry for the trouble, but I am just a user trying to understand why this
regression has not been fixed for over three months.  If this is the best the
Linux kernel community can do in response to my questions about this regression,
then in the long run, I can assure, you, the open source development model is
doomed to a slow, long, and eventually painful death.

Best regards,

Chuck

\
 
 \ /
  Last update: 2022-08-14 11:19    [W:0.081 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site