+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 > 😠> > +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 (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 >>> >>> <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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com.
