Hi everyone, I'd like to propose a cleanup of 'fork' relationships of the repositories in the jenkinsci GitHub organization.
Background: For many years, the plugin hosting process has forked existing repositories. The expectation was always that the new repo in jenkinsci was the canonical 'main' repository, but that wasn't enforced. For the past year or two, we've even asked maintainers to delete their repository after forking unless there were useful PRs and issues in there already, so that the jenkinsci repo became the 'main' repo (with occasional mishaps if someone else had forked before us). Some people enjoy the "branding" effect that having the source repository creates. But this comes with downsides: Sometimes GitHub code search doesn't work, depending on the popularity of the repository. Links to create pull requests sometimes don't work quite right, and INFRA-2697 notes that the GitHub CLI cannot really handle networks where a fork is the "main" repo, probably for the same reason. Having a different repo than what we consider canonical as the "root" repository confuses users trying to file pull requests or issues on GitHub. It'll get worse once GitHub adds repo-level discussions[1]. Basically, the more stuff is attached to a repository that isn't trivially cloned/mirrored to forks, the worse it gets. In terms of security, GitHub for quite some time did not support security warnings for forks. LGTM.com / GitHub Security Labs still does not recognize forked repositories. Earlier this year a security researcher recently used its CodeQL functionality to identify and submit fixes to pom.xml files referencing plain HTTP Maven repositories, but couldn't do that for forked repos. In many cases, the source repositories are much less active than the repo in jenkinsci, or the maintainers have moved on entirely, making this feature unavailable to (other) current maintainers, or the Jenkins security team. The way we create forks is simply not a well-supported use case. My proposal therefore is to "unfork" plugin and similar repositories in the jenkinsci organization. Only repositories that clearly are forks (e.g. some libraries not maintained by us) would remain forks. After checking with GitHub support, the following options exist: 1. It is possible to invert the fork relationship. This requires approval from both repo owners (i.e. jenkinsci and whoever we forked from). 2. It is possible to cut the fork relationship. This requires approval from the forked repo owner (i.e. jenkinsci). And while it is technically possible to re-attach repos to a network / merge networks, GH support would rather not do that. Therefore I propose we implement the following steps: 1. We try to contact, wherever possible, whoever we forked from, and ask them to contact GitHub support. I'll grant blanket permission on behalf of jenkinsci and will tell everyone the support ticket number to reference so this goes as smoothly as possible. 2. We wait a while while folks ask GH support for an inversion of the fork relationship. 3. We ask GitHub support to cut the fork relationship of everything that's left over. Additionally, we should change the hosting process to work with repo transfers, or creation of repos without the fork relationship. That can be done at any time though; as even now we don't really want that fork relationship we create to exist. To understand the scope of this, I've written a script that periodically updates a list of forked repositories in jenkinsci, you can see the result at https://www.jenkins.io/doc/developer/publishing/source-code-hosting/forks/ One potential problem are plugins that are actively maintained outside the jenkinsci organization and only have an outdated fork in jenkinsci that isn't being used. I think it makes sense to ask maintainers to move their activity into jenkinsci (including perhaps a complete repo transfer to retain issues and PRs). If they refuse, rather than cut the fork relationship, we could just delete our unused fork. (While this touches on plugins maintained exclusively outside jenkinsci, I consider that general topic to be a separate conversation. Please keep this thread focused on this proposal.) Thoughts? Daniel 1: https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net.
