> By the same logic, we could dispense with core PR reviews because any commit can be reverted without problems You're going on the extreme there. A PR merged in a release can be installed. A missing permission is not at that kind of level of impact.
> [...] witch hunt [...] To explicit my thinking process there that will also reply to the other comments. I do not want to put a clock ticking above the heads of any role, that would notify you "hey you have not merged a PR since 11 months, in 30 days you will be kicked". That's neither the goal nor the intent. > [...] I think it should’ve been discussed on the mailing list publicly For the CERT list, I will post a message in the mailing list before removing the inactive users. On Sunday, January 29, 2023 at 8:53:27 PM UTC+1 m...@basilcrow.com wrote: > On Sun, Jan 29, 2023 at 4:52 AM 'wfoll...@cloudbees.com' via Jenkins > Developers <jenkin...@googlegroups.com> wrote: > > Thanks for the positive feedback! > > It was positive feedback about the intention, not necessarily the end > result. > > > [To] widen the discussion before the act did not seem necessary. > Especially when such a change can be reversed without problems. > > By the same logic, we could dispense with core PR reviews because any > commit can be reverted without problems. Such an approach would appear > to go against the consensus-driven nature of the project. > > > Concerning the activities, the remaining people did at least a PR review > during the last year. > > That would make those people eligible to be members of the > core-pr-reviewers team, which has triage permissions but not write > permissions. Eligible members of the core team, which has write > permissions, would be those who have merged or closed a PR during the > last year. Can you see a flaw in my reasoning? > > > This is not strictly requiring the write permission, but I don't want to > do something that could be seen as a witch hunt. > > I do not see how it could be seen as that given the explicitly stated > goal (reducing the risk of security exposure), which has been > discussed transparently in this public thread. > > > This kind of risk reduction was rarely done in the past, I don't want to > be too aggressive on that. > > On the contrary, the fact that this kind of risk reduction was rarely > done in the past is all the more reason to act deliberately, > conciliarly, and thoroughly in the present: past precedent shows that > our decision is likely to stick for a long time. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b9083814-3598-4aef-af0b-de7baeb15827n%40googlegroups.com.
