Hi Alex,
On Wed, 23 Mar 2022 at 14:42, Alex Deucher alexdeucher@gmail.com wrote:
On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone daniel@fooishbar.org wrote:
On Wed, 23 Mar 2022 at 08:19, Christian König christian.koenig@amd.com wrote:
Well the key point is it's not about you to judge that.
If you want to complain about the commit message then come to me with that and don't request information which isn't supposed to be publicly available.
So to make it clear: The information is intentionally hold back and not made public.
In that case, the code isn't suitable to be merged into upstream trees; it can be resubmitted when it can be explained.
So you are saying we need to publish the problematic RTL to be able to fix a HW bug in the kernel? That seems a little unreasonable. Also, links to internal documents or bug trackers don't provide much value to the community since they can't access them. In general, adding internal documents to commit messages is frowned on.
That's not what anyone's saying here ...
No-one's demanding AMD publish RTL, or internal design docs, or hardware specs, or URLs to JIRA tickets no-one can access.
This is a large and invasive commit with pretty big ramifications; containing exactly two lines of commit message, one of which just duplicates the subject.
It cannot be the case that it's completely impossible to provide any justification, background, or details, about this commit being made. Unless, of course, it's to fix a non-public security issue, that is reasonable justification for eliding some of the details. But then again, 'huge change which is very deliberately opaque' is a really good way to draw a lot of attention to the commit, and it would be better to provide more detail about the change to help it slip under the radar.
If dri-devel@ isn't allowed to inquire about patches which are posted, then CCing the list is just a façade; might as well just do it all internally and periodically dump out pull requests.
Cheers, Daniel