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 <[email protected] > <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 > <[email protected] <javascript:>> wrote: > > >> On Dec 20, 2015, at 17:32, Baptiste Mathus >> <[email protected] <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 <[email protected] <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 [email protected] <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 [email protected] <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 [email protected] > <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 [email protected] <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 [email protected] > <mailto:[email protected]>. > 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 [email protected]. 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.
