Jenkins does not resolve around me. So I do not seek to try and make Jenkins community to jump to my timetable. all CloudBees employees know my time constraints anyway, so I do not feel the need to broadcast it in a public forum
On Monday 21 December 2015, Kanstantsin Shautsou <[email protected]> wrote: > What slots are suitable for you? Meeting time shift was discussed few > times but nothing changed. > > On Dec 21, 2015, at 14:58, Stephen Connolly < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > The current IRC time slot is not compatible with my family. I normally try > to ensure somebody who can attend is willing to represent my PoV when I > know there is an issue I feel strongly about > > On Monday 21 December 2015, Kanstantsin Shautsou < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> >> >> On Monday, December 21, 2015 at 2:58:34 AM UTC+3, Stephen Connolly wrote: >>> >>> 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 >>> >> + i closed all my >1 year old PRs when realised that 2.0 will be >> cosmetic. >> >>> >>> 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. >>> >> Do you really think that community has enough core devs not already hired >> by CB? I have problem with classloading and only 3 guys (you are one of) >> may have answer, all in CB. >> >>> >>> 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. >>> >> PR instead direct commit at least provides chance to get review, i think >> you are expecting review in PRs and not in master tree. Such review already >> happens, i.e. Daniel provides comments in all PRs. >> >>> >>> 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). >>> >> I may say that if it was open for 1 week, then community had enough time >> for review. Obviously CB relies on ability merging their payed changes >> faster and somebody may kick you for such blocker proposals :-) >> >>> 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. >>> >> And if it doesn't fit into current 1.x, then wait for 10 years to get >> ability (One of my first contributions >> https://github.com/jenkinsci/jenkins/pull/902#issuecomment-134412342 ) >> After CB hiring not all changes can be reviewed i.e. fundamental >> https://github.com/jenkinsci/jenkins/pull/1936#issuecomment-162191335. >> Of course there was no objections for merge. >> >>> >>> 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... >>> >> In PRs you may have degree of go asap/wait for community, while in >> direct commits there is nothing than "don't care". >> >>> Just my €0.02 >>> >>> -Stephen >>> >> Stephen, btw, could you attend meetings on IRC? >> >>> >>> On 20 December 2015 at 17:22, Andrew Bayer <[email protected]> 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]> wrote: >>>> >>>>> >>>>> On Dec 20, 2015, at 17:32, Baptiste Mathus <[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]>: >>>>> >>>>>> 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]. >>>>>> 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 >>>>> 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 >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> 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/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. >>>>> >>>> >>>> >>>> -- >>>> 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/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. >>>> >>> >>> >> -- >> 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/75c80dd2-6e06-4676-8a1e-bfb5bee688f7%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/75c80dd2-6e06-4676-8a1e-bfb5bee688f7%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from my phone > > -- > 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. > To unsubscribe from this group and all its topics, send an email to > [email protected] > <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwnuHMGT2P4L6UvTzAt0GX-qeUDpdFpFaDr_W8DwTos0Q%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwnuHMGT2P4L6UvTzAt0GX-qeUDpdFpFaDr_W8DwTos0Q%40mail.gmail.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] > <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/D4E4A607-84D3-4F22-B975-535C3E9EA313%40gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/D4E4A607-84D3-4F22-B975-535C3E9EA313%40gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- 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/CA%2BnPnMxcinEOiT-Y8sXUkpKivpoRBr03HxUgKzi5X1vyon-GDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
