> On Jun 9, 2015, at 01:12, Stephen Connolly <[email protected]> 
> wrote:
> 
> 
> 
> On Monday, June 8, 2015, Kanstantsin Shautsou <[email protected] 
> <mailto:[email protected]>> 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
>  
> <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  <>[email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/36f8761d-f3ff-4182-8000-cab492bbdd23%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/36f8761d-f3ff-4182-8000-cab492bbdd23%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 
> <https://groups.google.com/d/topic/jenkinsci-dev/HyFFJ2CP-iU/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxkzyp3YQjwgRzF%2Bk%3DprsxuX%2Bs2GEKocJ7ZU1w90AifOA%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxkzyp3YQjwgRzF%2Bk%3DprsxuX%2Bs2GEKocJ7ZU1w90AifOA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout 
> <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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/393DCE76-B689-44C8-BD05-3783403D0C3E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to