Hi Chris, On Thu, 2025-09-11 at 09:47 +0000, Christopher Klooz wrote: > I understand your point about proposal number (3 <-> 1). But I put them > together intentionally for several reasons.
But those reasons treat the separate proposals as kind of the same thing with the same solution. While they impact different sets of users and packagers. I really think it will be simpler to not bundle them. > Keep in mind that we already agreed in the original discussion that included > FESCo members that I am allowed & will do the changes to systemd, and also > agreed how I shall do it (it is already elaborated in the proposal). So the > means in the proposal are already agreed, including the how to do it, and it > is part of what people currently vote for. Prior discussions with a FESCO member that was favorable != pre- approval of your proposal or agreement by the impacted packagers that will have to adopt (and maintain) your new policies. > The proposal is already out and has some feedback. I think breaking the > discussions and withdrawing it and re-creating three different proposals > would cause more confusion than order anyway. I also don't think it is > useful. Having one or more focused proposals isn't a bad outcome of the Change Proposal process. Just on this mailinglist I already see various people disagreeing with the mechanism proposed for one or more parts. They might be OK with some parts and not others. > > force the systemd package maintainers to set that and then hope users will > > read some documentation to enable their installed packages to work again is > > a great policy. > I think you should read the proposal and potentially the discussion, which I > think you have not done yet, as most of what you state has been already > tackled. I have read the proposal and the other discussions on the forum. That is why I am replying to your change proposal. You seem to make that argument each time someone disagrees with your approach. But from what I can see all those people did read the discussion and are even aware/involved with the current policies around these capabilities. Please try to do some more research which packages your different proposals impact. Which I admit is hard because it isn't easy to know which packages need certain capabilities, use specific system calls or sys/proc file access. But just stating that you will obsolete an existing package and that packagers that now have a broken package can contact you so that you can document the breakage is imho not a great proposal. Please actively contact and work with the impacted package maintainers to see how they can help shape these change proposals. BTW. I am one of the maintainers of the default-yama-scope package you are proposing to obsolete and I was really surprised you didn't try to contact us before drafting this Change Proposal. Cheers, Mark -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
