Re: Proposal: forbid direct commits to master for core

rged quickly. > > - > Thomas > > From: on behalf of Stephen Connolly < > stephen.alan.conno...@gmail.com> > Reply-To: "jenkinsci-dev@googlegroups.com" > > Date: Tuesday, March 8, 2016 at 12:29 PM > To: "jenkinsci-dev@googlegroups.com" > Subject: Re: Propo

Re: Proposal: forbid direct commits to master for core

ailto:jenkinsci-dev@googlegroups.com>> Subject: Re: Proposal: forbid direct commits to master for core I think I am now against this proposal. At least without an agreed mechanism to make large cross-cutting changes without ending up in the: 1. Submit PR 2. Request review 3. Wait 4. If PR is

Re: Proposal: forbid direct commits to master for core

On 08.03.2016, at 22:45, Stephen Connolly wrote: > So you are saying that somebody making fix-ups won't make mistakes and the > changes do not need re-review? > > It's hard enough in the current process to know at what point you have the OK > to merge... Of course *some* merges are more co

Re: Proposal: forbid direct commits to master for core

On Wednesday, March 9, 2016 at 12:45:40 AM UTC+3, Stephen Connolly wrote: > > On 8 March 2016 at 20:39, Daniel Beck > > wrote: > >> >> On 08.03.2016, at 21:29, Stephen Connolly > > wrote: >> >> > 2. Request review >> > 3. Wait >> > 4. If PR is no-longer mergable, or needs fix-up due to other PRs

Re: Proposal: forbid direct commits to master for core

On 8 March 2016 at 20:39, Daniel Beck wrote: > > On 08.03.2016, at 21:29, Stephen Connolly > wrote: > > > 2. Request review > > 3. Wait > > 4. If PR is no-longer mergable, or needs fix-up due to other PRs merged, > Then fix up PR and Goto 2 > > FWIW I would not consider most fix ups cause to go

Re: Proposal: forbid direct commits to master for core

On 08.03.2016, at 21:29, Stephen Connolly wrote: > 2. Request review > 3. Wait > 4. If PR is no-longer mergable, or needs fix-up due to other PRs merged, Then > fix up PR and Goto 2 FWIW I would not consider most fix ups cause to go back to #2 if there have been positive reviews of the origi

Re: Proposal: forbid direct commits to master for core

I think I am now against this proposal. At least without an agreed mechanism to make large cross-cutting changes without ending up in the: 1. Submit PR 2. Request review 3. Wait 4. If PR is no-longer mergable, or needs fix-up due to other PRs merged, Then fix up PR and Goto 2 5. Merge PR steps 2-

Re: Proposal: forbid direct commits to master for core

Keeping just for logging of this topic to save future time during searching examples https://github.com/jenkinsci/jenkins/commit/bb7c8fcedbcc9b51c5b1bb5b32810af5ac6b1ffb -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe fr

Re: Proposal: forbid direct commits to master for core

Is it weird only for me https://github.com/jenkinsci/jenkins/pull/1301 ? Could somebody describe? -- 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 jenkinsc

Re: Proposal: forbid direct commits to master for core

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 plu

Re: Proposal: forbid direct commits to master for core

>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

Re: Proposal: forbid direct commits to master for core

Oh, definitely! On Dec 21, 2015 8:39 AM, "Arnaud Héritier" wrote: > > > On Sun, Dec 20, 2015 at 6:22 PM, 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. >>

Re: Proposal: forbid direct commits to master for core

On Sun, Dec 20, 2015 at 6:22 PM, 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

Re: Proposal: forbid direct commits to master for core

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 wrote: > What slot

Re: Proposal: forbid direct commits to master for core

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 > 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

Re: Proposal: forbid direct commits to master for core

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 wrote: > > > On Monday, December 21, 2015 at 2:58:34 AM

Re: Proposal: forbid direct commits to master for core

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

Re: Proposal: forbid direct commits to master for core

A few years ago the Gerrit workflow process was proposed, which can enforce a workflow on specific branches. You can then have GitHub repos synchronised out-of-the-box. See for instance the OpenStack project: - Gerrit reviews: https://review.openstack.org - GitHub:

Re: Proposal: forbid direct commits to master for core

> > 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 r

Re: Proposal: forbid direct commits to master for core

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 disagree

Re: Proposal: forbid direct commits to master for core

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 no

Re: Proposal: forbid direct commits to master for core

+1, absolutely. This would make the process more transparent. 2015-12-20 23:40 GMT+01:00 Christopher Orr : > 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 t

Re: Proposal: forbid direct commits to master for core

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

Re: Proposal: forbid direct commits to master for core

On Sunday, December 20, 2015 at 8:23:09 PM UTC+3, 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

Re: Proposal: forbid direct commits to master for core

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

Re: Proposal: forbid direct commits to master for core

> On Dec 20, 2015, at 17:32, Baptiste Mathus 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

Re: Proposal: forbid direct commits to master for core

+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... 2015-12-20 15:26 GMT+01:00 Oleg Nenashev : > Hi Kostya, > > I understand your concern, but m

Re: Proposal: forbid direct commits to master for core

Hi Kostya, I understand your concern, but messages of such kind can be considered as a personal offense. 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 di

Proposal: forbid direct commits to master for core

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/d86a88ab0