Forked repositories in GitHub

[Daniel Beck]

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net.

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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidp4dLModbJmw8BwL4XQCFA5tecb_D-M-mfEQrXA4Ybhw%40mail.gmail.com.

[Arnaud Héritier]

+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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

[Daniel Beck-2]

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

[Arnaud Héritier]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-9th%2B-9aezCgecy7MOSLu6O6cNBPBBsBSL8hht2Fc51nw%40mail.gmail.com.

[Arnaud Héritier]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU--x8GiZodH0uucAbmYkWNa%3Dp1BW4B82rUE8bbPMTOm6Xg%40mail.gmail.com.

[Mark Waite-2]

+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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

[Matt Sicker]

+1 here, especially due to GitHub tooling and apps.

On Tue, Aug 18, 2020 at 8:13 AM Mark Waite <[hidden email]> 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

😭

+1000 for the proposal

On Tue, Aug 18, 2020 at 2:01 PM Arnaud Héritier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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

--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com.

[Ulli Hafner]

+1 from me as well

Am 18.08.2020 um 16:30 schrieb Matt Sicker <[hidden email]>:

+1 here, especially due to GitHub tooling and apps.

On Tue, Aug 18, 2020 at 8:13 AM Mark Waite <[hidden email]> 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

😭

+1000 for the proposal

On Tue, Aug 18, 2020 at 2:01 PM Arnaud Héritier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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

--

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com.

[Liam Newman]

+1000

On Tue, Aug 18, 2020 at 3:20 PM Ullrich Hafner <[hidden email]> wrote:

+1 from me as well

Am 18.08.2020 um 16:30 schrieb Matt Sicker <[hidden email]>:

+1 here, especially due to GitHub tooling and apps.

On Tue, Aug 18, 2020 at 8:13 AM Mark Waite <[hidden email]> 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

😭

+1000 for the proposal

On Tue, Aug 18, 2020 at 2:01 PM Arnaud Héritier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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

--

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwZttYnAmV3S1KOFqJXrMU_0WtN1FuJigviOePij9vLTQ%40mail.gmail.com.

[Oleg Nenashev]

+1 from me.

Thanks for driving it, Daniel!

On Wednesday, August 19, 2020 at 12:37:15 AM UTC+2, Liam Newman wrote:

+1000

On Tue, Aug 18, 2020 at 3:20 PM Ullrich Hafner <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">ullric...@...> wrote:

+1 from me as well

Am 18.08.2020 um 16:30 schrieb Matt Sicker <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">msi...@...>:

+1 here, especially due to GitHub tooling and apps.

On Tue, Aug 18, 2020 at 8:13 AM Mark Waite <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mark.e...@...> 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 <a href="https://github.com/aheritier/build-flow-plugin/pull/2" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faheritier%2Fbuild-flow-plugin%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEt-LHqBP5zxVCA-YPY4qOwc6BiMQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faheritier%2Fbuild-flow-plugin%2Fpull%2F2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEt-LHqBP5zxVCA-YPY4qOwc6BiMQ&#39;;return true;">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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

+1 for the proposed plan

Something is strange in your export.

For example I am supposed to host <a href="https://github.com/aheritier/build-flow-plugin" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faheritier%2Fbuild-flow-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEHR6rY3KwQhJz2hznNa6F3g7vPA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Faheritier%2Fbuild-flow-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFEHR6rY3KwQhJz2hznNa6F3g7vPA&#39;;return true;">https://github.com/aheritier/build-flow-plugin (origin) which should be forked to <a href="https://github.com/jenkinsci/jenkinsci/build-flow-plugin" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkinsci%2Fbuild-flow-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyh6X_QvaNBHX4sz-mbEToZrXWBg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkinsci%2Fbuild-flow-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEyh6X_QvaNBHX4sz-mbEToZrXWBg&#39;;return true;">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 <[hidden email]> 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. <a href="http://LGTM.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2FLGTM.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWfK4vxevPCT7_nVkXEr4EmHfh1w&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2FLGTM.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWfK4vxevPCT7_nVkXEr4EmHfh1w&#39;;return true;">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 <a href="https://www.jenkins.io/doc/developer/publishing/source-code-hosting/forks/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.jenkins.io%2Fdoc%2Fdeveloper%2Fpublishing%2Fsource-code-hosting%2Fforks%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDTpSoXJhYPQQqG0EXT570AeTrHg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.jenkins.io%2Fdoc%2Fdeveloper%2Fpublishing%2Fsource-code-hosting%2Fforks%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHDTpSoXJhYPQQqG0EXT570AeTrHg&#39;;return true;">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: <a href="https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.blog%2F2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more%2F%23discussions\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEB5_7YePQrW5WETShPWbXB4d09iA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.blog%2F2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more%2F%23discussions\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEB5_7YePQrW5WETShPWbXB4d09iA&#39;;return true;">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 [e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/6D96DA83-2AE0-4C87-92D6-4CCC8DFE1E57%40beckweb.net&#39;;return true;">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 [e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-_vuzGEO_u18SkF43t1vSbZouZm7yq61-m9BCvj3dizMg%40mail.gmail.com.

--
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 [e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKTB1QCVTd-c1ABxBi3pf%2Bo8w-ODJu1Poq2vWjKX4Ot8g%40mail.gmail.com.

--

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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">[e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/50ad23a4-abe8-4a69-ab09-2419d227e830n%40googlegroups.com.

--

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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">[e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oz_CHTEH257FqacEOChDxEHTWj0SPOVTbt3%2BKKCSxnj0A%40mail.gmail.com.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dsmhUm2GAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">[e-mail].
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/48B64CEC-02A5-4797-95A2-6969F5F28C93%40gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/17131214-3c46-4907-91db-01c70cc9a18do%40googlegroups.com.

[Baptiste MATHUS]

+1. All for it. 

Le mar. 18 août 2020 à 13:38, Daniel Beck <[hidden email]> a écrit :

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 [hidden email].
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4PdgQgOpdtgNO5GEf0VhSU1Cq3ZmA-v6MhyBS-ZpWsEQ%40mail.gmail.com.