Protecting githib master branches against force-push

[oliver gondža]

It seems that Github started providing "Protected branches"[1]
functionality for free. Is this the right time to protect core's master
branch and suggest maintainers to do the same with plugins? Putting this
as a topic on governance meeting agenda.

[1]
https://github.com/blog/2051-protected-branches-and-required-status-checks

--
oliver

[Kanstantsin Shautsou]

It will only mask force-push to other branches. Better restrict access for right people for right repos.

[ogondza]

My idea was preventing incidents like [1] to happen.

I do not see a problem with force-pushing to feature branches (provided noone based ones work on that), not to mention we do not encourage people to create feature branches in core repo.

[1] http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th

--

oliver

[Kanstantsin Shautsou]

Branch may be more critical in plugin rather then master, so implicitly broke other branches is not a solution IMHO. 

Most maintainers has Admin access to their repos and can enable protection if they want, no need enforcing it.

About [1]. This person was not maintainer of all (?) repos that he broke, so why he has access WRITE to all of them?

IMHO happened because Kohsuke organised project in such way that everybody who don’t know about jenkins has write access everywhere and can f*** all plugins.

--
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/0ciUju7raOA/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/818ef4a1-8ced-4681-abeb-1468a550b2e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nicolas de loof]

The spirit of jenkins community has always been to lower the entry barrier as much as possible (aka "want to contribute ? you can commit now") which for most of us do immediately remind the "great power gives great responsibilities" spiderman-syndrom, and make people act with care and/or rely on PR for code they are not confident with.

--
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/E6354652-2BD7-4354-836A-C6D99E5EBB88%40gmail.com.

[Kanstantsin Shautsou]

On Sep 14, 2015, at 13:23, nicolas de loof <nicolas...@gmail.com> wrote:

The spirit of jenkins community has always been to lower the entry barrier as much as possible (aka "want to contribute ? you can commit now") which for most of us do immediately remind the "great power gives great responsibilities" spiderman-syndrom,

and make people act with care and/or rely on PR for code they are not confident with.

It was rhetorical question :)

This spirit based on the fact that project leader has no time for project, SPOF and blocker for almost any actions (btw other projects has periodic elections, but it another story). In such situation you providing write for new-comers that didn't guided how to work/code in this project (no description that it’s great, not obvious in current security days, power). This lower barrier with soft rules for first new comers allowed create dirty/hacky/unreadable code for current new comers aka (“want contribute? Don’t know jenkins/git/java/groovy/programming? you can commit now everywhere!”).

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzne67DEWgFznAqvK768ejYZMfMr2NGiZwF9THZWmRHSpA%40mail.gmail.com.

[oliver gondža]

On Mon, 14 Sep 2015 13:17:34 +0200, Kanstantsin Shautsou
<kanstan...@gmail.com> wrote:

> This spirit based on the fact that project leader has no time for
> project, SPOF and blocker for almost any actions (btw other projects has
> periodic elections, but it another story). In such situation you
> providing write for new-comers that didn't guided how to work/code in
> this project (no description that it’s great, not obvious in current
> security days, power). This lower barrier with soft rules for first new
> comers allowed create dirty/hacky/unreadable code for current new comers
> aka (“want contribute? Don’t know jenkins/git/java/groovy/programming?
> you can commit now everywhere!”).

If you have some suggestion to improve current process, suggest an
improvement. Enforcing you visions on unrelated PR/Issues/Process
improvements does not go anywhere.

--
oliver