On Monday, June 8, 2015, Kanstantsin Shautsou <[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
>
> 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.

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 [email protected]
> <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[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.
>


-- 
Sent from my phone

-- 
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/CA%2BnPnMxkzyp3YQjwgRzF%2Bk%3DprsxuX%2Bs2GEKocJ7ZU1w90AifOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to