On Fri, 6 Jan 2023 at 03:46, Michael Kubacki <mikub...@linux.microsoft.com> wrote: > > Hi Ard, > > I believe you're referencing the points in this mail, right? > https://edk2.groups.io/g/devel/message/97433 > > To be clear about why that was considered dismissive and passive > aggressive, these sentences: > > "I would also like to point out that all this focus on code aesthetics > that do not contribute to the object code at all is distracting from > things that would actually improve the safety and robustness of the > code." > > "So if you are interested, and want to improve EDK2 at a level that > actually makes the shipping code more robust, we could collaborate on > this (PE spec change, UEFI spec change, EDK2 and Linux changes both > for x86 and arm64[0]) so that firmware runs with indirect branch > protection enabled when the hardware supports it." > > Read as "this is unimportant/distracting so do this more important stuff > instead". >
Fair enough. It was never my intent to be disrespectful, though. > This may not been what you meant to convey, but it doesn't set the best > foundation for collaboration on the topic. > True. > I understand that there will always be functionally impacting work that > has tangible value over supporting changes like correctly spelling > words. Though, it's not purely aesthetic, language translators and > screen readers function more reliably if words are spelled correctly. In > any case, improving reading comprehension and functionality are not > mutually exclusive. > > I think we're meeting on the topic with two different sets of > expectations that naturally conflict. > > 1. You're not happy with the current process used for spell checking in > TianoCore > 2. I would like to prevent and/or minimize future patches that only fix > typos (check in CI) > 3. We both believe fixing spelling errors should be simple > > (1) is a valid opinion to have but because of (1), I cannot enable (2). > Because of (1), (3) is not true as the infrastructure needs to be > revamped, which I do not personally have bandwidth to do at the moment. > None of this would be problematic for me if I had the discretion as a long time maintainer to override/ignore certain CI errors. I don't see how this is fundamentally different from adding known typos to the exception list. > My initial understanding was that the TianoCore process had further > discussion and agreement than it seems occurred so I thought we (as a > community) were in position to simply follow it and reduce the typo > count. Without (2), the typos fixed can reappear (the next commit could > reintroduce the same typo without enforcement) so, in my opinion, it's > not worth the time and effort to manage the patch series in that case. > That's why I revoked the series. > Fair enough. > Your feedback is still valuable to the wider TianoCore Tools & CI group > that meets weekly. It may be able to be addressed there. > Those tend to take place in the middle of the night for me, which is why I rarely join those. > On the topic of IBT/BTI, I agree that's useful. We probably need to have > a dedicated thread on that to get more background on where you're at and > then we can try to help where possible. > > Would you be open to a meeting to discuss that? > Yes, please. I'm in UTC+1, and my calendar is generally fairly empty, so please feel free to set a time that works for you. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98301): https://edk2.groups.io/g/devel/message/98301 Mute This Topic: https://groups.io/mt/95678218/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
