+1, absolutely. This would make the process more transparent.

2015-12-20 23:40 GMT+01:00 Christopher Orr <[email protected]>:

> 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 a new repo in the GitHub organisation?
>
> Regards,
> Chris
>
>
> On 20/12/15 18:22, 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 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] <mailto:[email protected]>> wrote:
> >
> >
> >>     On Dec 20, 2015, at 17:32, Baptiste Mathus <[email protected]
> >>     <mailto:[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]
> >>     <mailto:[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/CANWgJS6rCP30auJMMc_C71iY8hS-FVHLqVVHfE6K3DQfDMGc7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to