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]> 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/CA%2BnPnMwOY3eqKhzKZBEUaqumWVv4uBXufxHZwcLXtBgWynkaCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to