On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi Alex, > > On Wed, 23 Mar 2022 at 14:42, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > > On Wed, 23 Mar 2022 at 08:19, Christian König <christian.koenig@xxxxxxx> 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. I think we are in agreement. I think the withheld information Christian was referring to was on another thread with Christian and Paul discussing a workaround for a hardware bug: https://www.spinics.net/lists/amd-gfx/msg75908.html Alex Alex
