Hi, sorry, but it out of this topic. Jenkinsci project model is bazaar. I see no any reasons for enforcing somebody unrelated to reasons why plugin was created causing delays by asking why some company needs host some plugin. Somebody created plugin and share for mass usage, you may use it or not. Delays for development ends with cases when people start hosting plugins on their own servers. What can be really critical for review - it’s not obvious things like pluginId (that unfortunately is hardcoded to artifactId), license, etc. Hope partially it will be possible automate by having maven enforcer plugin.
>>> 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. The same for plugins, if *author* of plugin doesn’t want to use PRs, then you can’t enforce him do it (the reason why i left docker-plugin development). Core is critical for stability and relates to many devs/contributors, that’s why i created this topic/proposal. > On Dec 21, 2015, at 01:40, Christopher Orr <[email protected]> wrote: > > 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]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >>> On Dec 20, 2015, at 17:32, Baptiste Mathus <[email protected] >>> <mailto:[email protected]> >>> <mailto:[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]> >>> <mailto:[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? >>> >>> 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 >>> >>> <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 >>> <https://github.com/jenkinsci/jenkins/pull/1914> one >>> person is doing direct master >>> changes >>> https://github.com/jenkinsci/jenkins/commit/653fbdb65024b1b528e21f682172885f7111bba9 >>> >>> <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 >>> >>> <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]> >>> <mailto:[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> >>> >>> <https://groups.google.com/d/msgid/jenkinsci-dev/630f6633-d494-4726-8c21-d63890ce040a%40googlegroups.com?utm_medium=email&utm_source=footer >>> >>> <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 >>> <https://groups.google.com/d/optout>. >>> >>> >>> >>> >>> -- >>> Baptiste <Batmat> MATHUS - http://batmat.net <http://batmat.net/> >>> <http://batmat.net/ <http://batmat.net/>> >>> Sauvez un arbre, >>> Mangez un castor ! > > -- > 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/d64UIypbzh0/unsubscribe > <https://groups.google.com/d/topic/jenkinsci-dev/d64UIypbzh0/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/56772E49.7000803%40orr.me.uk > <https://groups.google.com/d/msgid/jenkinsci-dev/56772E49.7000803%40orr.me.uk>. > 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/C3288469-C2D9-449D-B049-4102529DFD68%40gmail.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
