Proposal: remove write permissions from everyone github team and assign committers to real repositories/teams

[Kanstantsin Shautsou]

Hi, i want raise this question for discussion. I think this is partially a project security issue.

Any new/not experienced/unrelated to XX plugin new-comer receives access to 1k repos and this looks for me very bad because:

1) you can accidentally push and kill somebodies work

2) On other side as plugin maintainer/developer you have no any guarantee that somebody will push to your repo. 

3) Bad from security viewpoint

Current infra has ability for adding persons to repositories, but this step is constantly ignored by people that granting permissions (and i think irc bot had some related bugs).

When you assigned to repository you can also:

1) change repository settings: configure labels/issues/wiki 

2) See and highlight real plugin developers by https://help.github.com/articles/writing-on-github/#name-and-team-mentions-autocomplete 

3) Maintainer can grant permissions to the next maintainer (add to plugin team)

I see no any problems with having "read" for everyone (for tracking how many people are involved), "write" for teams and assign people to repositories/teams. (For all plugins where i was involved i firstly added myself to team to indicate that i do commits).

What other people think? If this bad idea please provide other possible variants for highlighted text.

[Stephen Connolly]

I actually think our community has grown by virtue of being liberal with the commit bit.

What is the comparison with how core committers have grown after adding the CLA "speed bump"?

I can see people being precious with the commit bit for "their" project all over the interwebs... I am sometimes guilty of the same myself if I don't pay attention... But one thing that Jenkins has thought me is that OSS works better when you are liberal with the commit bit.

It can be hard enough to let people feel empowered enough to cut releases on a repo where the maintainer has gone awol (eg violations after Peter relocated to Colorado with job title that leaves him less concerned with the details of the CI server)

Or even get people realise that they are effectively now a co-maintainer of the project.

I worry that limiting the commit bit would harm the community.

In addition, are you not trying to solve the wrong problem. 

* Overwriting of commits is a problem that should be solvable, eg a bot that slurps the RSS feeds of commits, captures the hashes of overwritten commits and stashes them off to a "parallel" organisation where it maintains a read-only clone of all repos and creates tags of the overwrites and emails the overwritten user... That is one possible solution, better can be found, but it shows that issue is solveable

* giving somebody a commit bit is no guarantee that anyone will commit anything to a project. PRs are really where commits (of the drive-by varietals) come from. The need here is to close out PRs. Perhaps even a bot that autocommits PRs without a comment from a committer after 2 months if mergeable ... (Causes side-effects ;-) )

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/36f8761d-f3ff-4182-8000-cab492bbdd23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Kanstantsin Shautsou]

On Jun 9, 2015, at 01:12, Stephen Connolly <stephen.al...@gmail.com> wrote:

On Monday, June 8, 2015, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

Hi, i want raise this question for discussion. I think this is partially a project security issue.

Any new/not experienced/unrelated to XX plugin new-comer receives access to 1k repos and this looks for me very bad because:

1) you can accidentally push and kill somebodies work

2) On other side as plugin maintainer/developer you have no any guarantee that somebody will push to your repo. 

3) Bad from security viewpoint

Current infra has ability for adding persons to repositories, but this step is constantly ignored by people that granting permissions (and i think irc bot had some related bugs).

When you assigned to repository you can also:

1) change repository settings: configure labels/issues/wiki 

2) See and highlight real plugin developers by https://help.github.com/articles/writing-on-github/#name-and-team-mentions-autocomplete 

3) Maintainer can grant permissions to the next maintainer (add to plugin team)

I see no any problems with having "read" for everyone (for tracking how many people are involved), "write" for teams and assign people to repositories/teams. (For all plugins where i was involved i firstly added myself to team to indicate that i do commits).

What other people think? If this bad idea please provide other possible variants for highlighted text.

I actually think our community has grown by virtue of being liberal with the commit bit.

Because there is no better alternatives and design fits to many cases.

What is the comparison with how core committers have grown after adding the CLA "speed bump”?

Sorry what do you mean? Core is very sensitive and requires quality so not everybody allowed to do commits.

I can see people being precious with the commit bit for "their" project all over the interwebs... I am sometimes guilty of the same myself if I don't pay attention... But one thing that Jenkins has thought me is that OSS works better when you are liberal with the commit bit.

OSS works better when commits has quality (good code/review/tests/design) and not just a “i committed this fix and don’t care”. I see real examples where people fails on quality because trying to do commits everywhere and it reflects negatively on jenkins (as a project) quality. (Probably it is the main reason why i at all decided to join jenkins development. For other different tools like maven, gradle, artifactory and etc i have no such many problems).

It can be hard enough to let people feel empowered enough to cut releases on a repo where the maintainer has gone awol (eg violations after Peter relocated to Colorado with job title that leaves him less concerned with the details of the CI server)

Add yourself to this plugin “team” and continue your work, what is the problem? Your IRC client is running 24/7 and you need only type one command to jenkins-admin. For some people i even already provided forgotten repository permissions and IRC voices (caused by constant problem with de-authenticated jenkins-admin bot).

Or even get people realise that they are effectively now a co-maintainer of the project.

The same, no problem, add to team and do commits. You don’t need to have commit permission to 1k repos if you are co-mointaining 1 repo. I do myself this and helped many other persons - the same can do anyone. 

I worry that limiting the commit bit would harm the community.

If permissions were granted right (everyone for tracking and committer for repo) then nothing required at all. 

In addition, are you not trying to solve the wrong problem. 

* Overwriting of commits is a problem that should be solvable, eg a bot that slurps the RSS feeds of commits, captures the hashes of overwritten commits and stashes them off to a "parallel" organisation where it maintains a read-only clone of all repos and creates tags of the overwrites and emails the overwritten user... That is one possible solution, better can be found, but it shows that issue is solveable

If it interests conflict like it was in email-ext, then it must go to relations discussions.

* giving somebody a commit bit is no guarantee that anyone will commit anything to a project. PRs are really where commits (of the drive-by varietals) come from. The need here is to close out PRs. Perhaps even a bot that autocommits PRs without a comment from a committer after 2 months if mergeable ... (Causes side-effects ;-) )

Sounds weird for me. AFAIK with read permission you can open PRs, but you will have no merge button. Please correct me if i’m wrong.

-- 
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/36f8761d-f3ff-4182-8000-cab492bbdd23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my phone

-- 

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/HyFFJ2CP-iU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxkzyp3YQjwgRzF%2Bk%3DprsxuX%2Bs2GEKocJ7ZU1w90AifOA%40mail.gmail.com.

[Kanstantsin Shautsou]

https://wiki.jenkins-ci.org/display/JENKINS/IRC+Bot#IRCBot-GitHubrepositories maybe somebody missed this info, but it two separate commands.

[Daniel Beck]

On 09.06.2015, at 00:12, Stephen Connolly <stephen.al...@gmail.com> wrote:

> I actually think our community has grown by virtue of being liberal with the commit bit.

I don't think this proposal disputes that, or wants to _really_ limit what you can do if you request it.

However, I agree with Kostya (a rare enough event :-) ) that the current system of giving everyone commit access everywhere by default, doesn't help, but harm.

> I can see people being precious with the commit bit for "their" project all over the interwebs... I am sometimes guilty of the same myself if I don't pay attention... But one thing that Jenkins has thought me is that OSS works better when you are liberal with the commit bit.

Seems a bit like a straw man argument. Properly executed we wouldn't even need to limit significantly what permissions we hand out. People need to ask today already to get their initial permissions and that mostly works fairly well. We could also add some automation to it to make it even more seamless: Ask, and if nobody objects for a few days, you're in. We just wouldn't give them permissions to commit to the 1000+ repos they didn't even request. I don't think that a significant number of people use their commit access to more that 3-5 repos, or frequently change what they need access to. And those few developers that do are known and can be safely excluded from this rule.

> It can be hard enough to let people feel empowered enough to cut releases on a repo where the maintainer has gone awol (eg violations after Peter relocated to Colorado with job title that leaves him less concerned with the details of the CI server)
>
> Or even get people realise that they are effectively now a co-maintainer of the project.

Could this be related to the fact that hundreds of users have the same authority to release the project as you have?

> I worry that limiting the commit bit would harm the community.

I worry that not limiting the commit bit will harm the community. I provided a (luckily hypothetical) example in the May 13 governance meeting[1]. We ran out of time before we could really discuss this, unfortunately.

1: http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-05-13-18.07.log.html from 19:03-19:16