On Wed, Jul 10, 2024 at 9:38 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > I'm guessing Josh's response was an attempt to use AI to generate a > summary. In the future, please label it as such, so people will read > it with a critical eye. It has some flaws which I will address inline: Yep, because the summary from the tool was pointless. If I do this again, I'll label it as such. Thank you for the additional context. I think it helps the community understand the issues at hand better. > On Wed, Jul 10, 2024 at 6:56 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Jul 9, 2024 at 3:14 PM Josh Stone <jistone@xxxxxxxxxx> wrote: > > > > > > Text Log: > > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.txt > > > HTML Log: > > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.log.html > > > Text Minutes: > > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.txt > > > HTML Minutes: > > > https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-07-09/fesco.2024-07-09-17.00.html > > > > > > Meeting summary > > > --------------- > > > * TOPIC: Init Process (@jistone:fedora.im, 17:00:24) > > > * TOPIC: #3231 Update exception request for rust-add-determinism > > > (@jistone:fedora.im, 17:06:22) > > > * AGREED: An update exception is explicitly granted to > > > rust-add-determinism for Fedora <= 40, but not yet for 41+ (+8, 1, -0) > > > (@jistone:fedora.im, 17:28:55) > > > * TOPIC: #3232 Change: Mark Fedora KDE AArch64 as Release-Blocking > > > (@jistone:fedora.im, 17:29:21) > > > > The discussion revolved around the proposal to designate Fedora KDE > > AArch64 disk images as release-blocking for Fedora 41 and potentially > > subsequent releases. Here are the key topics discussed and decisions > > made: > > > > Proposal Context: The proposal was to elevate Fedora KDE AArch64 disk > > images to release-blocking status starting from Fedora 41, with > > concerns about the high failure rate of live ISO images. > > This is unintentionally conflating two different issues. The KDE team > was originally proposing that BOTH live ISOs and disk images be > blocking. Due to discussion prior to the meeting, they withdrew the > live ISO proposal due to the failure rate. > > > > > Failure Rate and Infrastructure: There was acknowledgment of a > > significant failure rate (~50%) for live ISO images, prompting plans > > to migrate to a more stable build system (Kiwi) for Fedora 42. > > Additionally, discussions touched on exploring separate server > > infrastructure due to funding and support limitations for automated > > testing. > > This is tangential to the proposal on the table, but accurate. > > > QA and SIG Collaboration: Debate ensued over whether QA resources > > could handle the additional testing workload, with a suggestion that > > SIGs (Special Interest Groups) should contribute more actively to > > testing and bug fixing. > > > > ARM SIG Input: There was a consensus that input from the ARM SIG was > > crucial, given the impact on ARM platforms. Concerns were raised about > > whether the ARM SIG had the necessary resources and whether they > > should be involved in decisions regarding blocking status. > > "Consensus" is an overstatement. From my personal opinion, this was an > attempt to delay making a decision, because there was no clear > statement made about WHAT feedback, exactly, is needed from the ARM > SIG. > > > > Decision Making Process: The proposal faced some opposition due to > > concerns about the practicality and cost-effectiveness of making > > changes without adequate resources. Ultimately, a decision was > > deferred pending further input from the ARM SIG. > > This is not exactly true. The opposition was due to the lack of > current resources, with a debate over the chicken-and-egg problem of > whether volunteers should expend their own money to provide hardware > to perform release-blocking testing without the release-blocking > status. Some FESCo members feel that the hardware needs to be > satisfied before approving release-blocking status, whereas the KDE > SIG does not feel like it should be expected to spend money until they > know it will directly serve a purpose. > > > Future Steps: It was agreed to postpone the final decision, gather > > input from the ARM SIG, and revisit the proposal in the next meeting > > to ensure all stakeholders' concerns are adequately addressed. > > The conversation was going in circles and FESCo latched on "get info > from the ARM SIG" as a way to end the current conversation so we could > move on to the other topics. That's a more cynical way of saying the same thing :) > > In summary, while there was initial support for the proposal to > > designate Fedora KDE AArch64 disk images as release-blocking, concerns > > about testing resources, infrastructure limitations, and the need for > > ARM SIG input led to a decision to delay the final vote and gather > > more information before proceeding. > > That's an acceptable summary, I suppose. > > > > > * TOPIC: #3233 Change: GIMP version 3 (@jistone:fedora.im, 18:00:57) > > > * AGREED: FESCo would like to see the proposal reworked. We also > > > require that GIMP v2 must not be present in Fedora 41+ due to python 2 > > > removal. (+9, 0, -0) (@jistone:fedora.im, 18:06:27) > > > * TOPIC: #3234 Change: Replace Nose with Pynose (@jistone:fedora.im, > > > 18:07:15) > > > * AGREED: Change: Replace Nose with Pynose (+0, 0, -7) > > > (@jistone:fedora.im, 18:18:58) > > > * TOPIC: #3238 Change: Nvidia Driver Installation with Secure Boot > > > (@jistone:fedora.im, 18:19:22) > > > * LINK: > > > https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034#note_2162304 > > > (@sgallagh:fedora.im, 18:20:36) > > > > In the discussion regarding FESCO issue #3238 on July 9, 2024, the > > main topic centered around enabling Nvidia driver installation with > > Secure Boot in Fedora. Here are the key points and decisions made: > > > > Introduction and Background: > > > > The issue was introduced by amoloney, and it aims to address the > > challenge of installing Nvidia drivers under Secure Boot in Fedora. > > > > The issue was introduced by @eischmann and @mcrha, with Aoife facilitating. > > > Concerns and Discussions: > > > > Participants expressed concerns about the security implications of > > allowing locally stored signing keys, which could potentially > > compromise Secure Boot's integrity. > > Various approaches and comparisons were made with other distributions > > like Ubuntu and openSUSE, which handle similar challenges differently. > > Accurate. > > > Proposed Compromises: > > > > There was a suggestion to improve user experience by making the > > process of enabling Nvidia drivers sufficiently cautionary to mitigate > > risks. > > That was my suggested compromise, though it received considerable pushback. > > > Discussion included technical challenges such as limitations in UEFI > > NVRAM for storing keys and potential vulnerabilities in the update > > process. > > Yes, although that summary vastly understates the complexity involved. It's a summary. The point of a summary is to outline an issue enough to explain it in a manner that those interested in details know whether it's worth reading the details... :) > > Decision and Next Steps: > > > > Despite extensive discussion, consensus on a solution was not reached > > during the meeting. > > It was decided to postpone further discussion to a future meeting due > > to time constraints and the complexity of the issue. > > Concerns about potential security risks and the need for a robust > > solution that doesn't compromise overall system security were > > highlighted. > > Accurate, but again understated. > > > > > Overall, the meeting focused on the technical and security > > implications of the proposed change, with participants leaning towards > > caution and further exploration of viable solutions. > > All of this is true, but it's one-sided. It describes the security > concerns, but it fails to mention that the intent of the proposal is > also addressing a major *usability* concern of Fedora. Someone reading > only this summary would naturally conclude that FESCo should reject > this Change, but it's not that simple. Then I would encourage FESCo to look at providing better summaries of their meetings, because the initial summary leaves the user concluding FESCo didn't really discuss anything. We have the technology. It took me 4 minutes to produce the summaries of these two topics and I copied them verbatim. The chair sending the summary out could easily use the same tech to get a better summary and then edit it for accuracy. I think that would actually serve the community better than what is posted now. josh -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
