Removing the Everyone team in the jenkinsci GitHub org

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Richard Bywater-2
That sounds like a reasonable approach to me.

Semi related question re "I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo."

Should a plugin maintainer have full admin access to the repo? Reason I ask is that I recently took over as maintainer for the HTML publisher plugin but don't have any access outside of committing etc. As the maintainer should I have slightly more access?

Thanks
Richard.

On Tue, 28 Nov 2017 at 13:25 Daniel Beck <[hidden email]> wrote:
Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/CAMui9466JbUq2SOrYdLR9Bu-08W4wGzh%2BG_qATcJR3xc3EUk1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck

> On 28. Nov 2017, at 01:39, Richard Bywater <[hidden email]> wrote:
>
> Should a plugin maintainer have full admin access to the repo? Reason I ask is that I recently took over as maintainer for the HTML publisher plugin but don't have any access outside of committing etc. As the maintainer should I have slightly more access?

Sooo… fun fact: You only have write access to that repo because you're in Everyone. Good news: With 18 contributions, you'd get direct access in this process ;-)

Added you to the dedicated per-repo team, and granted Admin access. For a while I used to reduce the access level of the 'foo-plugin Developers' team manually from Admin to Write, the reason being the "Danger Zone" options usually available to repo admins (transfer/delete/… repo). Those can now be disabled for repo admins org-wide, so we routinely grant Admin access to maintainers again.

--
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/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Richard Bywater-2
Great - thanks for your help Daniel!

Richard.

On Tue, 28 Nov 2017 at 14:13 Daniel Beck <[hidden email]> wrote:

> On 28. Nov 2017, at 01:39, Richard Bywater <[hidden email]> wrote:
>
> Should a plugin maintainer have full admin access to the repo? Reason I ask is that I recently took over as maintainer for the HTML publisher plugin but don't have any access outside of committing etc. As the maintainer should I have slightly more access?

Sooo… fun fact: You only have write access to that repo because you're in Everyone. Good news: With 18 contributions, you'd get direct access in this process ;-)

Added you to the dedicated per-repo team, and granted Admin access. For a while I used to reduce the access level of the 'foo-plugin Developers' team manually from Admin to Write, the reason being the "Danger Zone" options usually available to repo admins (transfer/delete/… repo). Those can now be disabled for repo admins org-wide, so we routinely grant Admin access to maintainers again.

--
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/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/CAMui946Wsi6_f6H64Y9YFKO3t_H%3D50ZL-LnFzVyyuzjx8zwPNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Mark Waite-2
That sounds reasonable to me.

I won't remove "Everyone" from the git-client-plugin or the git-plugin until after you've made the change, since removing that group would remove write permission for key people (Stephen, Jesse, Sam, Liam, etc.).

I don't seem to be able to add people to either the git-client-plugin-developers group or to the git-plugin-developers group.  Is that expected?

Mark Waite

On Mon, Nov 27, 2017 at 6:18 PM Richard Bywater <[hidden email]> wrote:
Great - thanks for your help Daniel!

Richard.

On Tue, 28 Nov 2017 at 14:13 Daniel Beck <[hidden email]> wrote:

> On 28. Nov 2017, at 01:39, Richard Bywater <[hidden email]> wrote:
>
> Should a plugin maintainer have full admin access to the repo? Reason I ask is that I recently took over as maintainer for the HTML publisher plugin but don't have any access outside of committing etc. As the maintainer should I have slightly more access?

Sooo… fun fact: You only have write access to that repo because you're in Everyone. Good news: With 18 contributions, you'd get direct access in this process ;-)

Added you to the dedicated per-repo team, and granted Admin access. For a while I used to reduce the access level of the 'foo-plugin Developers' team manually from Admin to Write, the reason being the "Danger Zone" options usually available to repo admins (transfer/delete/… repo). Those can now be disabled for repo admins org-wide, so we routinely grant Admin access to maintainers again.

--
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/11E33829-614A-4979-A037-AE5CDD899367%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/CAMui946Wsi6_f6H64Y9YFKO3t_H%3D50ZL-LnFzVyyuzjx8zwPNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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/CAO49JtF2SU14VEuAZ1bEonOSduAigdth4bNAsqMiNmw4shLO5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Kohsuke Kawaguchi
Administrator
In reply to this post by Daniel Beck
Thanks for driving this. 

If this change inadvertently remove somebody's commit access, presumably we expect people to follow this and mail this list?

On Mon, Nov 27, 2017 at 4:25 PM Daniel Beck <[hidden email]> wrote:
Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
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/CAN4CQ4xLdArgFQDYw0weXhZpmzgdzGs0sDvKG%2Ba9xy%3DeTD7-9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Robert Sandell-2
3. Have at least 5 'contributions' (~commits in the contributors graph)

A mid sized pr normally sits around 5 commits, so does one merged pr count as five contributions?

/B

2017-11-28 4:58 GMT+01:00 Kohsuke Kawaguchi <[hidden email]>:
Thanks for driving this. 

If this change inadvertently remove somebody's commit access, presumably we expect people to follow this and mail this list?

On Mon, Nov 27, 2017 at 4:25 PM Daniel Beck <[hidden email]> wrote:
Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
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/CAN4CQ4xLdArgFQDYw0weXhZpmzgdzGs0sDvKG%2Ba9xy%3DeTD7-9g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Robert Sandell
Software Engineer
CloudBees Inc.

--
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/CALzHZS1VO_Hd3dLeSw-QT2A%3D3aY5TfuR6VOUrddGvcC4DO_M_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
In reply to this post by Mark Waite-2

> On 28. Nov 2017, at 03:39, Mark Waite <[hidden email]> wrote:
>
> I won't remove "Everyone" from the git-client-plugin or the git-plugin until after you've made the change, since removing that group would remove write permission for key people (Stephen, Jesse, Sam, Liam, etc.).

Right, 14 people for git-plugin and three (ndeloof, stephenc, jglick) in git-client-plugin would get added to the repo.

> I don't seem to be able to add people to either the git-client-plugin-developers group or to the git-plugin-developers group.  Is that expected?

Usually controlled via IRC bot, but I have no problem handing out team maintainerships on request. Others just add people as 'external contributors' directly which requires just admin access to the repo, bypassing the per-repo team system.

--
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/E7D5651F-168F-4A22-9C7A-11DEE245C375%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
In reply to this post by Kohsuke Kawaguchi

> On 28. Nov 2017, at 04:58, Kohsuke Kawaguchi <[hidden email]> wrote:
>
> If this change inadvertently remove somebody's commit access, presumably we expect people to follow this and mail this list?

Or just email this list in panic/rage without following a guide ;-)

That's why I plan to keep the logs of this around, to check whether this change (and why) resulted in access removed.

--
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/5BDF2221-AB60-4DBE-AE20-3237480716C7%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
In reply to this post by Robert Sandell-2

> On 28. Nov 2017, at 11:26, Robert Sandell <[hidden email]> wrote:
>
> A mid sized pr normally sits around 5 commits, so does one merged pr count as five contributions?
>

I think so (perhaps unless squashed?). Note that this does not grant additional commit access to people who don't already have it from Everyone. It's the threshold to effectively not have it revoked. I'm flexible on the threshold here, or what other (easy to determine, GH API is a mess) criteria to apply, suggestions welcome.

Once this is implemented, it'll be straightforward to provide reports who has access to which repo (beyond just clearly showing it in each repo's collaborators form), and plugin maintainers can clean this up further.

--
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/4FCB0DEA-C0D1-4B3A-ADD6-F09531615009%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Baptiste MATHUS
+1. A sensible move for sure. With hundreds of repos and hundreds of committers, /some/ segregation can definitely help avoid screwing up, even from non malicious users.

Thanks Daniel for that cleanup

2017-11-28 11:50 GMT+01:00 Daniel Beck <[hidden email]>:

> On 28. Nov 2017, at 11:26, Robert Sandell <[hidden email]> wrote:
>
> A mid sized pr normally sits around 5 commits, so does one merged pr count as five contributions?
>

I think so (perhaps unless squashed?). Note that this does not grant additional commit access to people who don't already have it from Everyone. It's the threshold to effectively not have it revoked. I'm flexible on the threshold here, or what other (easy to determine, GH API is a mess) criteria to apply, suggestions welcome.

Once this is implemented, it'll be straightforward to provide reports who has access to which repo (beyond just clearly showing it in each repo's collaborators form), and plugin maintainers can clean this up further.

--
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/4FCB0DEA-C0D1-4B3A-ADD6-F09531615009%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/CANWgJS4Jnvx4dKCdpUP7JXSaKmyGA3mRG6MMN%2BGJzZ91s7J8wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Jesse Glick-4
In reply to this post by Daniel Beck
Generally +1 for sure. Minor comment:

On Mon, Nov 27, 2017 at 7:25 PM, Daniel Beck <[hidden email]> wrote:
> Have at least 5 'contributions' (~commits in the contributors graph)
>
> […] GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request

I am not sure what you consider “efficient” in this context, but it
certainly seems easy enough to see who has merged pull requests in the
past, unless they use the "rebase” option which I think is pretty
unusual. Both true merges and squashes via the UI leave a standard
pattern in the commit message, and most command-line PR merges (again
true merges or squashes) would also refer to the PR number in the
commit message. Should be possible to put together some kind of simple
script to grep for such commits, then group and count by committer.

Creation of tags per se is indeed not recorded outside the reflog,
which we lack access to, but in practice most tags in most repository
are created by `maven-release-plugin`, which again leaves a standard
commit message format that we could easily search for.

To be clear, it does not seem unreasonable to (continue to) grant
write permission to people who have already had a number of
contributions accepted; I was just unclear on why you think we cannot
detect maintainer-like actions (merging PRs, cutting releases) with
decent confidence.

--
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/CANfRfr0YVXpytbCfFf-zEX4J%3D5X_KDpB%3Da0cmLhUy8jzy62-uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

R. Tyler Croy
In reply to this post by Daniel Beck
+1, go-go-gadget githubfixings

On Tue, 28 Nov 2017, Daniel Beck wrote:

> Hi everyone,
>
> For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.
>
> While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).
>
> I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.
>
> Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.
>
> Right now, I plan to grant direct write access to a plugin to users who:
>
> 1. Have write access to a repository through the Everyone team only
> 2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
> 3. Have at least 5 'contributions' (~commits in the contributors graph)
>
> The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.
>
> So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.
>
> While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.
>
> I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.
>
> Daniel
>
> --
> 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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
- R. Tyler Croy

------------------------------------------------------
     Code: <https://github.com/rtyler>
  Chatter: <https://twitter.com/agentdero>
     xmpp: [hidden email]

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------

--
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/20171128161537.dwovaj4kmxbznizj%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
In reply to this post by Jesse Glick-4

> On 28. Nov 2017, at 16:46, Jesse Glick <[hidden email]> wrote:
>
> I was just unclear on why you think we cannot
> detect maintainer-like actions (merging PRs, cutting releases) with
> decent confidence.

Note that the GH API doesn't work just based on Git data (in fact, those are somewhat separate entirely) -- we can know the users performing even a rebase PR merge.

But I've chewed through 4+ hours worth of API rate limits just with the basic approach I've used yesterday to list existing permissions. Enumerating all merged PRs for all repos, then looking at who merged them, plus checking all release commits for the associated GitHub user would take quite a long time.

And in the end, there's plenty of Gradle-based repos, maintainers doing their own thing without PR contributions, etc. where these rules fall flat, so requiring these to retain access would just serve to remove legitimate access in many cases. Both are just approximations of where we want to be, and it's not clear that spending that additional effort will be worth it.

Starting by getting rid of Everyone is a much quicker win, and further improvements can be applied once we've significantly reduced the number of users we even need to look at for every repo. I prefer approaching this step by step to not overwhelm both contributors and maintainers, and my ability to sort out any potential messes I cause.

--
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/E6C2AF7C-A085-4E3A-A227-FFC6B1DBEC24%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Jesse Glick-4
On Tue, Nov 28, 2017 at 11:30 AM, Daniel Beck <[hidden email]> wrote:
> I've chewed through 4+ hours worth of API rate limits just with the basic approach I've used yesterday to list existing permissions. Enumerating all merged PRs for all repos, then looking at who merged them, plus checking all release commits for the associated GitHub user would take quite a long time.

./jenkinsci/backend-merge-all-repo/clone.groovy

and then do it from the command line.

--
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/CANfRfr02y15ooMuDWipLHSbCPW0p0i%2Bqt921T%3DZ%2B6-QYus90kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Ulli Hafner
In reply to this post by Daniel Beck
Seems that I still can push changes to my repositories but I cannot access the settings anymore (e.g., edit the description, view the collaborators). Is this doable per IRC bot? 

How should the new structure in collaborators look like? I’m not sure if I just missed that part in your mail…
Should there be only a * developers team? Or should there be a developers and admin team? Or individual users?


Am 28.11.2017 um 01:25 schrieb Daniel Beck <[hidden email]>:

Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/C5B832CF-81CD-4E41-A332-02835A4904A9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc (540 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Robert Sandell-2
I don't think I've ever been able to access the settings and edit the description of the repos I maintain :'(

/B

2017-11-29 9:56 GMT+01:00 Ullrich Hafner <[hidden email]>:
Seems that I still can push changes to my repositories but I cannot access the settings anymore (e.g., edit the description, view the collaborators). Is this doable per IRC bot? 

How should the new structure in collaborators look like? I’m not sure if I just missed that part in your mail…
Should there be only a * developers team? Or should there be a developers and admin team? Or individual users?


Am 28.11.2017 um 01:25 schrieb Daniel Beck <[hidden email]>:

Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--
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/C5B832CF-81CD-4E41-A332-02835A4904A9%40gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Robert Sandell
Software Engineer
CloudBees Inc.

--
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/CALzHZS0vWDWkqJCPjrZ7MEP4QqRcjUGgKnrjoaSUhSt0pgnW7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck
In reply to this post by Ulli Hafner

> On 29. Nov 2017, at 09:56, Ullrich Hafner <[hidden email]> wrote:
>
> Seems that I still can push changes to my repositories but I cannot access the settings anymore (e.g., edit the description, view the collaborators).

AFAICT you never were. I've looked into this about a year ago already, and you stood out as _the_ maintainer getting permissions from Everyone team -- and that has long (always?) only granted Write access.

> Is this doable per IRC bot?

Yes, as that bot adds to per-repo team, which will still be around.

> How should the new structure in collaborators look like? I’m not sure if I just missed that part in your mail…
> Should there be only a * developers team? Or should there be a developers and admin team? Or individual users?

Details TBD. I currently plan to make people collaborators with write access. This will need to be cleaned up some time in the future, but speculatively granting additional permissions (most per-repo teams grant admin access) doesn't sit right with me.

> BTW: you also need to update https://jenkins.io/projects/infrastructure/ircbot/

Yep, thanks. The comment 'make NAME a committer' will need to be removed, only 'make NAME a committer of REPO' will remain. We've only used the latter for a while now anyway.

--
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/19674B47-638B-4040-B9A4-F3009138E3AE%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Kanstantsin Shautsou-2
In reply to this post by Kohsuke Kawaguchi
Last time Kohsuke blocked this question with his veto because jenkinsci should be a bazaar model (and everybody should be able to work on any plugin). 
What happened since last time when i (and some other persons) tried to implement this and remove RW from everyone? 
Kohsuke, do you publicly approve that jenkins is not the bazaar anymore? 
PS Or JEP now removes King of project position?

Thanks.
On Tuesday, November 28, 2017 at 6:58:53 AM UTC+3, Kohsuke Kawaguchi wrote:
Thanks for driving this. 

If this change inadvertently remove somebody's commit access, presumably we expect people to follow <a href="https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin#AdoptaPlugin-Requestcommitaccess" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FAdopt%2Ba%2BPlugin%23AdoptaPlugin-Requestcommitaccess\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXTBscTe04OCGJLMUNzP4Ml0yJ9Q&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.jenkins.io%2Fdisplay%2FJENKINS%2FAdopt%2Ba%2BPlugin%23AdoptaPlugin-Requestcommitaccess\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGXTBscTe04OCGJLMUNzP4Ml0yJ9Q&#39;;return true;">this and mail this list?

On Mon, Nov 27, 2017 at 4:25 PM Daniel Beck <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ABIWouiUBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">m...@...> wrote:
Hi everyone,

For a long time, we didn't really manage GitHub permissions for plugins: We just added new repos and contributors to the 'Everyone' team, giving everyone access to everything, and that was it. Contrary to its name, it doesn't actually include _everyone_, at least not anymore: We've moved away from adding people to the Everyone team over a year ago. But it still has hundreds of members, and provides write access to more than 1200 repositories.

While contributors are mostly well-behaved, we've occasionally seen PRs merged by people who weren't regular contributors to those plugins, resulting in conflict with actual maintainers. Since these users cannot release the plugins anyway, the benefit of being able to do this is questionable at best. Not to mention the problem of malicious or accidental data loss through people force-pushing into Git (this, accidentally, has happened with dozens -- hundreds? -- of repositories back in 2015, and caused a considerable mess).

I know that quite a few plugin maintainers have long removed the Everyone team from their plugin repositories to prevent such problems, but the default is still to add the team to a new plugin repo.

Given the size of the Jenkins project, this is untenable. I plan to remove the Everyone team from all repositories, instead granting direct access to contributors who previously got their write access from the Everyone team. This way, we should be able to retain access for those who legitimately have it, while removing those who have no relationship to any particular plugin.

Right now, I plan to grant direct write access to a plugin to users who:

1. Have write access to a repository through the Everyone team only
2. Are considered 'contributors' by GitHub (meaning they have commits associated with them in the repo)
3. Have at least 5 'contributions' (~commits in the contributors graph)

The first two should be obvious (with the caveat that badly set up GH accounts -- their commits not associated with the account -- will lose access). The third is where it gets tricky: Not everyone who contributed to a repository, and currently has write access to it via 'Everyone' team, should legitimately have write access to it in the future. Unfortunately, GitHub makes it impossible to efficiently determine who has performed various maintainer-specific actions, such as created a release tag, or merged a pull request -- and these might still miss legitimate co-maintainers who just don't have direct access.

So I will instead use a minimum number (currently 5) of contributions required for someone to retain access. Once we've drastically limited who has access to any given repo, we can always fine-tune this later. There will also be a log of what changed so this can be referenced later in case of questions related to lost permissions.

While this may be a painful change if the above rules get the needed permissions wrong, it's an important one, and I'm trying to make it as smooth as possible. Please bring up your concerns and questions in this thread and I'll do my best to address them.

I don't think this is JEPable, as this doesn't actually create a longer-running process, it's just a one-time legacy permission migration.

Daniel

--
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="ABIWouiUBQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
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/bd3419ac-7f79-45aa-83c0-d9527cde54af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Removing the Everyone team in the jenkinsci GitHub org

Daniel Beck

> On 30. Nov 2017, at 00:17, Kanstantsin Shautsou <[hidden email]> wrote:
>
> Kohsuke, do you publicly approve that jenkins is not the bazaar anymore?

Could we please keep this thread focused on the specific proposed initiative?

--
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/DEB6ED3C-255C-4047-9C5A-C63706E1B7EA%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
12