On 21/12/15 09:33, Oleg Nenashev 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'm +1 on it. My gut-feeling that there are misusages: forking of > demo-only plugins, bad namings, etc. > It's enforceable. We could restrict the create repo permission to admins > only. > The restriction of the IRC bot is also possible when we have a > "community team".
I'm sure some admins are also guilty of forking their own plugins.. :) > > 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. > > > At least it's a good place to start. > > I see lots of PRs languishing for ages with disagreement over what > to do and no clear outcome one way or the other...] > > > It's a complete off-topic in any case... > Jenkins does not belong to CloudBees as well the company does not belong > to the project. All Jenkins contributors including CB-employed ones can > designate their review time as they want/can. Obviously we use our > working time to review "our" PRs, but it does not mean that nobody from > CB reviews other PRs during his spare time. Honestly I don't see much > unreviewed PRs, but if there are such ones you can always ask for a > review in the ML. The old pending PRs have been also classified. > > We have no "formal" PR review process in the community. If somebody > drafts a proposal, it would be a good topic for the discussion. > > понедельник, 21 декабря 2015 г., 2:58:34 UTC+3 пользователь Stephen > Connolly написал: > > If we are going to go down the road of forbidding direct committing > to master and forcing people to go through PRs (let's assume we can > find a way to let release commits go through) we'd need a better > criteria for when we can actually merge PRs. > > I see lots of PRs languishing for ages with disagreement over what > to do and no clear outcome one way or the other... > > We have 25 PRs that are older than Jun 1st 2014... > > 50 PRs that are at least 1 year old > > 75 PRs that are 6 months or older > > Now KS, it's not CloudBees place to decide what the community wants > to have merged... the community has not defined how to address these > PRs... > > If we are to move to PRs without direct commit then I want to see a > defined process whereby no PR goes more than say 1 month without the > community deciding if it is a Go / No Go on the general idea. > > I am quite sure that CloudBees would be willing to help get PRs into > a better state for merging if we knew that those PRs were the > direction the community wanted to go. Right now we seem to end up > saying "ok this is what we think, here's our contribution, do you > want it?" and there is no movement further... after a while we then > remove our CloudBees hat and don our core contributors hat and say > something like "ah for jebus's sake, nobody else has expressed an > opinion either way for the past 2-3 weeks, let's just merge it" but > don't for one second think that we like doing this. > > I would say that the community needs to show interest in PRs before > we can switch to a PR model as the route for change. > > My suggestion is that when a PR has been open for a week or so, the > community should start a vote thread to decide if the change is the > right direction (Go) or the wrong direction (No Go). If No Go then > close the PR providing the reason... if Go then the PR author can be > helped to get the PR to a mergeable quality and then we merge the > change and move forward. > > If that process gets all the open PRs down such that most PRs are > open for no more than 1 month, then and only then would I say that > preventing direct core commits might be worth pursuing... > > Just my €0.02 > > -Stephen > > On 20 December 2015 at 17:22, Andrew Bayer <andrew...@gmail.com > <javascript:>> 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 > <kanstan...@gmail.com <javascript:>> wrote: > > >> On Dec 20, 2015, at 17:32, Baptiste Mathus >> <m...@batmat.net <javascript:>> 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 <o.v.ne...@gmail.com <javascript:>>: >> >> 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 >> >> <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://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 jenkinsci-de...@googlegroups.com <javascript:>. >> 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 >> <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 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 jenkinsci-de...@googlegroups.com <javascript:>. >> To view this discussion on the web >> visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS61D%2BXzO0Xd8jV2icNU27mJSTGZM5R0OM8rNme12ZnEFg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS61D%2BXzO0Xd8jV2icNU27mJSTGZM5R0OM8rNme12ZnEFg%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 jenkinsci-de...@googlegroups.com > <javascript:>. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jenkinsci-dev/D11D841C-4F09-4893-95C4-F5B146F25C88%40gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/D11D841C-4F09-4893-95C4-F5B146F25C88%40gmail.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 jenkinsci-de...@googlegroups.com <javascript:>. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOb9uQr5_ebS82FeMJoBp32xRKU541rkGoMrw2YTN-apaw%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOb9uQr5_ebS82FeMJoBp32xRKU541rkGoMrw2YTN-apaw%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 jenkinsci-dev+unsubscr...@googlegroups.com > <mailto:jenkinsci-dev+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/f00a8e19-eee2-41a0-8a7a-d6d419c0da2f%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-dev/f00a8e19-eee2-41a0-8a7a-d6d419c0da2f%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5678910A.60608%40orr.me.uk. For more options, visit https://groups.google.com/d/optout.
