Hi Daniel Completely agree with this, I've accidentally submitted PRs to the wrong forks many times. Both because of GitHub CLI and also just the web UI picking the wrong one.
For the record I've had GitHub support break the fork relationship from all the components that I maintain as far as I know. and it all went fine :) Thanks Tim On Tue, 18 Aug 2020 at 12:39, Daniel Beck <m...@beckweb.net> wrote: > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net > . > -- 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/CAH-3Bidp4dLModbJmw8BwL4XQCFA5tecb_D-M-mfEQrXA4Ybhw%40mail.gmail.com.
