The repo exists, there's just an additional "jenkinsci/" in the link. I have no idea why the GH API behaves inconsistently there.
On Tue, Aug 18, 2020 at 1:50 PM Arnaud Héritier <[email protected]> wrote: > +1 for the proposed plan > Something is strange in your export. > For example I am supposed to host > https://github.com/aheritier/build-flow-plugin (origin) which should be > forked to https://github.com/jenkinsci/jenkinsci/build-flow-plugin ( > doesn't exist) > We probably had such repo in the past and it was deleted after I forked it > but maybe you could exclude from the list the repos when they aren't > existing anymore in the jenkinsci side (not sure how many repos could be > like this) > > On Tue, Aug 18, 2020 at 1:39 PM Daniel Beck <[email protected]> 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 [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 >> . >> > > > -- > Arnaud Héritier > Twitter/Skype : aheritier > > -- > 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/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.
