Seems that I still can push changes to my repositories but I cannot access the settings anymore (e.g., edit the description, view the collaborators). Is this doable per IRC bot?
How should the new structure in collaborators look like? I’m not sure if I just missed that part in your mail… Should there be only a * developers team? Or should there be a developers and admin team? Or individual users? BTW: you also need to update https://jenkins.io/projects/infrastructure/ircbot/ <https://jenkins.io/projects/infrastructure/ircbot/> > Am 28.11.2017 um 01:25 schrieb Daniel Beck <m...@beckweb.net>: > > 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/C5B832CF-81CD-4E41-A332-02835A4904A9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP
