Slightly hijacking this topic: would it be worthwhile having a similar rule (even if it's may not be technically enforceable) for creating new plugins?
i.e. everyone should have to go through the hosting request process, even if they already have, by whatever means, permission to create themselves a new repo in the GitHub organisation? Regards, Chris On 20/12/15 18:22, Andrew Bayer wrote: > So, addressing a few aspects of this thread: > > - I'd strongly oppose ICLA/push permission revocation for pushing > directly to master. That's overly harsh. > - I do support this policy overall - I'm personally a big fan of a > "Review then Commit" policy. > - There is a caveat/exception, of course - release-related commits. > > I think this is worth proposing for the next meeting - Kostya, could you > add it to the agenda on the wiki? There's no need to name-and-shame > specific cases of people pushing directly to master - this is a > worthwhile policy to advocate even if no one was actually breaking it at > this point. > > A. > > > On Sun, Dec 20, 2015 at 9:41 AM, Kanstantsin Shautsou > <[email protected] <mailto:[email protected]>> wrote: > > >> On Dec 20, 2015, at 17:32, Baptiste Mathus <[email protected] >> <mailto:[email protected]>> wrote: >> >> +1 with all Oleg said... >> The subject might indeed be eligible to discussion, and I also >> think we might want to proceed with only PRs, but the way you do >> it... >> And the name you use for kk in CC is, well… > Name was allowed, see meeting logs. >> >> 2015-12-20 15:26 GMT+01:00 Oleg Nenashev <[email protected] >> <mailto:[email protected]>>: >> >> Hi Kostya, >> >> I understand your concern, but messages of such kind can be >> considered as a personal offense. > Any question can be transformed in any way you want. >> >> Kohsuke is not the only person committing in such way, so it's >> definitely a wider problem, which requires a discussion. BTW >> currently there is no policy prohibiting such approach, so the >> direct commits are generally valid even if they smell bad. > Never saw anybody else, could you share more examples? >> >> >> I'm +1 on prohibiting direct pushes to the master branches for >> everybody and in all repos. And Jenkins core core is not an >> exception. >> It makes the current release and changelogging approach a bit >> problematic, but it's another story. >> >> if you signed ICLA and do some questionable changes into >> master (here i see 2 violations) person should get core >> access removal, right? >> >> >> Nope. There is no such policy in Jenkins project. If you have >> any concerns about particular contributors, raise the topic to >> the governance meeting. It's the *ONLY* way for discussing >> such topics. > That what core committers said to me when i asked about ICLA and > perms. Would be glad to see documented way without double standards. >> >> >> >> воскресенье, 20 декабря 2015 г., 17:03:40 UTC+3 пользователь >> Kanstantsin Shautsou написал: >> >> Situation: people doing reviews, blocking PRs for >> weeks,months,years while some people do direct commits to >> core master without any reviews. >> This ends to situations when master gets broken state that >> reflects on PR builds verification, >> i.e. >> https://github.com/jenkinsci/jenkins/commit/d86a88ab042cc55530d91e745af9e0886e8eeb79 >> Unreviewed changes adds chaos. While people reviewing and >> close to get rid of unconfigurable settings >> in https://github.com/jenkinsci/jenkins/pull/1914 one >> person is doing direct master >> changes >> https://github.com/jenkinsci/jenkins/commit/653fbdb65024b1b528e21f682172885f7111bba9 >> >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fjenkins%2Fcommit%2F653fbdb65024b1b528e21f682172885f7111bba9&sa=D&sntz=1&usg=AFQjCNGfejtJii5ClN4CxzyDP_BzWpWFag> >> >> Proposal: stop doing such unreviewed changes and forbid >> direct master commits (either at all, either only for >> mentioned person). >> >> PS. AFAIR/AFAIK if you signed ICLA and do some >> questionable changes into master (here i see 2 violations) >> person should get core access removal, right? >> >> >> -- >> 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/630f6633-d494-4726-8c21-d63890ce040a%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/630f6633-d494-4726-8c21-d63890ce040a%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Baptiste <Batmat> MATHUS - http://batmat.net <http://batmat.net/> >> Sauvez un arbre, >> Mangez un castor ! -- 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/56772E49.7000803%40orr.me.uk. For more options, visit https://groups.google.com/d/optout.
