Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

2017-10-27 Thread Kohsuke Kawaguchi 
Thanks!

On Fri, Oct 27, 2017 at 12:50 PM Liam Newman  wrote:

> Updates:
>
>- All proposed changes have been merged
>- BDFL Delegates are fully described
>- Governance meeting has oversight of BDFL
>- Added JEP Template to the PR
>
> https://github.com/jenkinsci/jep/pull/12 is now fully up-to-date and
> comments made so far have been addressed.
>
> I believe JEP-1 is on the agenda for the next governance meeting.  Please
> review the PR and any propose fixes/changes now.
>
>
> On Tuesday, October 24, 2017 at 7:08:47 PM UTC-7, Liam Newman wrote:
>>
>> There's been quiet a bit of discussion offline about this
>> I've closed #18 as Kohsuke's objections to it make it a non-starter.
>>
>> I've instead opened
>> * https://github.com/jenkinsci/jep/pull/19 that restores BDFL delegates
>> * https://github.com/bitwiseman/jep/pull/1 proposed amendment to #19
>> that adds Governance meeting oversight of BDFL.
>>
>> Comments welcome, PR's with proposed fixes preferred.
>>
>>
>> On Friday, October 20, 2017 at 11:08:27 AM UTC-7, Kohsuke Kawaguchi wrote:
>>>
>>> I admit I kept my eyes off this ball for a while. Naturally, I'm
>>> surprised at this change.
>>>
>>> My understanding was that this change is being considered as a reaction
>>> to those two concerns:
>>>
>>> > 1. Kohsuke as the BDFL introduces a problematic bottleneck to the
>>> process
>>> >(there are way more of us, than there are of him).
>>> >
>>> > 2. JEP-1 introduces a different way of decision making than has been
>>> >traditionally followed with the Governance Meeting
>>> >(https://jenkins.io/project/governance/#meeting)
>>>
>>> I prefer the original "BDFL + Delegate" model. I'd like to explain the
>>> reasons, and why that model adequately address those concerns. This is
>>> going to be a long post.
>>>
>>>
>>> First, the bottleneck point. As Bobby said in this thread and was
>>> discussed in the contributor summit, I understood my role in this process
>>> to be more like British Queen or Japanese Emperor, in the sense that I'm
>>> expected to designate Delegate in each area and let them lead those areas,
>>> as opposed to Supreme Court Justice who preside over individual cases. That
>>> is, the idea is to influence Delegates instead of influencing JEPs. In this
>>> manner, I don't think BDFL will be a bottleneck.
>>>
>>> The obvious question then would be how I pick Delegate. I think most
>>> area has natural leads that owns the spaces. For example, Daniel leads
>>> security related things, Oleg leads remoting, Jesse leads Pipeline, and so
>>> on. Those people currently have implicit influences, and we know who they
>>> are. I intend to designate them as Delegate. I will discuss that
>>> designation beforehand to eliminate any chance of surprises.
>>>
>>> This brings me to one of the reasons why I'm supporting JEP. Today,
>>> people who lead various efforts do so solely based on implicit influence.
>>> But this scheme doesn't work well as we scale up. I see the Delegate title
>>> as a way to make those implicit influences more explicit, so that people
>>> who are not spending as much time in the project or contributors from
>>> organizations can easily identify them as the primary go-to guy. Put
>>> differently, I want the Delegate title to help those people lead more
>>> effectively. The officer title worked very well with this regard. I think
>>> of Delegate as technical version of it. Obviously, we don't want Delegate
>>> to be dictators any more than you want BDFL to be actual dictator.And that
>>> spirit is captured in JEP. We expect Delegate to understand implicit
>>> influences of other people in neighboring areas and bring them in as
>>> appropriate.
>>>
>>> One of the problems I have with the proposed self-nominated Reviewer
>>> scheme is that it does not help with this regard. There's no explicit title
>>> like "Delegate" to clarify the role of leads. Those leads still need to
>>> rely solely on implicit influences.
>>>
>>>
>>> Back to how to pick Delegate. When we start a new effort, in the area
>>> where there's no existing effort, say Jenkins 2 or pluggable storage, I
>>> expect the initial JEP to capture goals and high level requirements of that
>>> effort. I will be the reviewer of that initial JEP, but as a part of that
>>> JEP I expect the Delegate to be determined for that space. Oftentimes the
>>> sponsor of that JEP should be the obvious choice as the Delegate as the
>>> leader of the effort. Other times we may need to have more discussions
>>> among the core developers to determine that person. Subsequent JEP in that
>>> space, to the extent it stays within the charter of the initial JEP, should
>>> be presided by that Delegate.
>>>
>>> This brings me to another reason why I'm supporting JEP. Organized
>>> contributors (aka companies putting their people into the project, as
>>> opposed to individuals participating on their own initiatives) need this
>>> kind of marking the space

Solved security problems in PostBuildScript Plugin

2017-10-27 Thread Daniel Heid 
Hi everyone,I tried to fix the arbritrary code execution vulnerability in the PostBuildScript plugin by using the SecureGroovyScript recommendation (https://wiki.jenkins.io/display/JENKINS/Script+Security+Plugin).You'll find the pull request here:https://github.com/jenkinsci/postbuildscript-plugin/pull/15If Gregory doesn't maintain the plugin any longer, I volunteer to adopt it. What do you think about that, Gregory?My GitHub and jenkins.io IDs are both dheidKind regardsDaniel



-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/59d803a8-5d53-4296-9462-625499a30f9b%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

2017-10-27 Thread Liam Newman 
Updates:

   - All proposed changes have been merged
   - BDFL Delegates are fully described
   - Governance meeting has oversight of BDFL
   - Added JEP Template to the PR

https://github.com/jenkinsci/jep/pull/12 is now fully up-to-date and 
comments made so far have been addressed.

I believe JEP-1 is on the agenda for the next governance meeting.  Please 
review the PR and any propose fixes/changes now. 


On Tuesday, October 24, 2017 at 7:08:47 PM UTC-7, Liam Newman wrote:
>
> There's been quiet a bit of discussion offline about this
> I've closed #18 as Kohsuke's objections to it make it a non-starter. 
>
> I've instead opened
> * https://github.com/jenkinsci/jep/pull/19 that restores BDFL delegates
> * https://github.com/bitwiseman/jep/pull/1 proposed amendment to #19 that 
> adds Governance meeting oversight of BDFL.
>
> Comments welcome, PR's with proposed fixes preferred.  
>
>
> On Friday, October 20, 2017 at 11:08:27 AM UTC-7, Kohsuke Kawaguchi wrote:
>>
>> I admit I kept my eyes off this ball for a while. Naturally, I'm 
>> surprised at this change.
>>
>> My understanding was that this change is being considered as a reaction 
>> to those two concerns:
>>
>> > 1. Kohsuke as the BDFL introduces a problematic bottleneck to the 
>> process
>> >(there are way more of us, than there are of him).
>> >
>> > 2. JEP-1 introduces a different way of decision making than has been
>> >traditionally followed with the Governance Meeting
>> >(https://jenkins.io/project/governance/#meeting)
>>
>> I prefer the original "BDFL + Delegate" model. I'd like to explain the 
>> reasons, and why that model adequately address those concerns. This is 
>> going to be a long post.
>>
>>
>> First, the bottleneck point. As Bobby said in this thread and was 
>> discussed in the contributor summit, I understood my role in this process 
>> to be more like British Queen or Japanese Emperor, in the sense that I'm 
>> expected to designate Delegate in each area and let them lead those areas, 
>> as opposed to Supreme Court Justice who preside over individual cases. That 
>> is, the idea is to influence Delegates instead of influencing JEPs. In this 
>> manner, I don't think BDFL will be a bottleneck.
>>
>> The obvious question then would be how I pick Delegate. I think most area 
>> has natural leads that owns the spaces. For example, Daniel leads security 
>> related things, Oleg leads remoting, Jesse leads Pipeline, and so on. Those 
>> people currently have implicit influences, and we know who they are. I 
>> intend to designate them as Delegate. I will discuss that designation 
>> beforehand to eliminate any chance of surprises.
>>
>> This brings me to one of the reasons why I'm supporting JEP. Today, 
>> people who lead various efforts do so solely based on implicit influence. 
>> But this scheme doesn't work well as we scale up. I see the Delegate title 
>> as a way to make those implicit influences more explicit, so that people 
>> who are not spending as much time in the project or contributors from 
>> organizations can easily identify them as the primary go-to guy. Put 
>> differently, I want the Delegate title to help those people lead more 
>> effectively. The officer title worked very well with this regard. I think 
>> of Delegate as technical version of it. Obviously, we don't want Delegate 
>> to be dictators any more than you want BDFL to be actual dictator.And that 
>> spirit is captured in JEP. We expect Delegate to understand implicit 
>> influences of other people in neighboring areas and bring them in as 
>> appropriate.
>>
>> One of the problems I have with the proposed self-nominated Reviewer 
>> scheme is that it does not help with this regard. There's no explicit title 
>> like "Delegate" to clarify the role of leads. Those leads still need to 
>> rely solely on implicit influences.
>>
>>
>> Back to how to pick Delegate. When we start a new effort, in the area 
>> where there's no existing effort, say Jenkins 2 or pluggable storage, I 
>> expect the initial JEP to capture goals and high level requirements of that 
>> effort. I will be the reviewer of that initial JEP, but as a part of that 
>> JEP I expect the Delegate to be determined for that space. Oftentimes the 
>> sponsor of that JEP should be the obvious choice as the Delegate as the 
>> leader of the effort. Other times we may need to have more discussions 
>> among the core developers to determine that person. Subsequent JEP in that 
>> space, to the extent it stays within the charter of the initial JEP, should 
>> be presided by that Delegate.
>>
>> This brings me to another reason why I'm supporting JEP. Organized 
>> contributors (aka companies putting their people into the project, as 
>> opposed to individuals participating on their own initiatives) need this 
>> kind of marking the space in which they execute in. Before driving a 
>> non-trivial effort, there needs to be discussion and consensus that the 
>> project accepts the

Re: How to hide files in WorkSpace

2017-10-27 Thread Robert Sandell 
Use the credentials plugin for that.
https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc

/B

2017-10-26 17:48 GMT+02:00 phanikumar :

> I had a requirement where I need to hide the Secret key files with Jenkins
> plugin. On the other hand, I need workspace files to be available for
> access. I found .git files visible in the workspace which are hidden files.
> Any suggestion is really appreciated.
>
>
>
> --
> Sent from: http://jenkins-ci.361315.n4.nabble.com/Jenkins-dev-f387835.html
>
> --
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/1509032922785-0.post%40n4.nabble.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS11FUBD76c52%2BY-pH-HocGXQYi9FVy3DzRL%3DWRaOA8FXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.