+1 from me as well > Am 18.08.2020 um 16:30 schrieb Matt Sicker <[email protected]>: > > +1 here, especially due to GitHub tooling and apps. > > On Tue, Aug 18, 2020 at 8:13 AM Mark Waite <[email protected] > <mailto:[email protected]>> wrote: > +1 from me. > > On Tuesday, August 18, 2020 at 6:03:07 AM UTC-6 Arnaud Héritier wrote: > and I received a PR https://github.com/aheritier/build-flow-plugin/pull/2 > <https://github.com/aheritier/build-flow-plugin/pull/2> > 😠> > +1000 for the proposal > > > On Tue, Aug 18, 2020 at 2:01 PM Arnaud Héritier <[email protected] <>> wrote: > ok I missed :( > It doesn't make sense to have my repo as primary. I didn't create it and > never committed to it. > There is probably a bug in GitHub with forks which were created a long time > ago > > On Tue, Aug 18, 2020 at 1:58 PM Daniel Beck <[email protected] <>> wrote: > 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 > <https://github.com/aheritier/build-flow-plugin> (origin) which should be > forked to https://github.com/jenkinsci/jenkinsci/build-flow-plugin > <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/ > <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 > > <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 > > <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 > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com?utm_medium=email&utm_source=footer>. > > > -- > Arnaud Héritier > Twitter/Skype : aheritier > > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > Matt Sicker > Senior Software Engineer, CloudBees > > -- > 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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%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/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com.
