That sounds like a reasonable approach to me. Semi related question re "I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo."
Should a plugin maintainer have full admin access to the repo? Reason I ask is that I recently took over as maintainer for the HTML publisher plugin but don't have any access outside of committing etc. As the maintainer should I have slightly more access? Thanks Richard. On Tue, 28 Nov 2017 at 13:25 Daniel Beck <m...@beckweb.net> wrote: > Hi everyone, > > For a long time, we didn't really manage GitHub permissions for plugins: > We just added new repos and contributors to the 'Everyone' team, giving > everyone access to everything, and that was it. Contrary to its name, it > doesn't actually include _everyone_, at least not anymore: We've moved away > from adding people to the Everyone team over a year ago. But it still has > hundreds of members, and provides write access to more than 1200 > repositories. > > While contributors are mostly well-behaved, we've occasionally seen PRs > merged by people who weren't regular contributors to those plugins, > resulting in conflict with actual maintainers. Since these users cannot > release the plugins anyway, the benefit of being able to do this is > questionable at best. Not to mention the problem of malicious or accidental > data loss through people force-pushing into Git (this, accidentally, has > happened with dozens -- hundreds? -- of repositories back in 2015, and > caused a considerable mess). > > I know that quite a few plugin maintainers have long removed the Everyone > team from their plugin repositories to prevent such problems, but the > default is still to add the team to a new plugin repo. > > Given the size of the Jenkins project, this is untenable. I plan to remove > the Everyone team from all repositories, instead granting direct access to > contributors who previously got their write access from the Everyone team. > This way, we should be able to retain access for those who legitimately > have it, while removing those who have no relationship to any particular > plugin. > > Right now, I plan to grant direct write access to a plugin to users who: > > 1. Have write access to a repository through the Everyone team only > 2. Are considered 'contributors' by GitHub (meaning they have commits > associated with them in the repo) > 3. Have at least 5 'contributions' (~commits in the contributors graph) > > The first two should be obvious (with the caveat that badly set up GH > accounts -- their commits not associated with the account -- will lose > access). The third is where it gets tricky: Not everyone who contributed to > a repository, and currently has write access to it via 'Everyone' team, > should legitimately have write access to it in the future. Unfortunately, > GitHub makes it impossible to efficiently determine who has performed > various maintainer-specific actions, such as created a release tag, or > merged a pull request -- and these might still miss legitimate > co-maintainers who just don't have direct access. > > So I will instead use a minimum number (currently 5) of contributions > required for someone to retain access. Once we've drastically limited who > has access to any given repo, we can always fine-tune this later. There > will also be a log of what changed so this can be referenced later in case > of questions related to lost permissions. > > While this may be a painful change if the above rules get the needed > permissions wrong, it's an important one, and I'm trying to make it as > smooth as possible. Please bring up your concerns and questions in this > thread and I'll do my best to address them. > > I don't think this is JEPable, as this doesn't actually create a > longer-running process, it's just a one-time legacy permission migration. > > Daniel > > -- > 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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAMui9466JbUq2SOrYdLR9Bu-08W4wGzh%2BG_qATcJR3xc3EUk1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
