Re: Jenkins Terminology cleanup continued - sub-terms for controllers

['Gavin Mogan' via Jenkins Developers]

If a class name is serialized or used external to the plugin, its super
hard to change without breaking compatibility. Generally the initial push
is for using facing changes. Text strings, Help files. Docs. Etc

On Tue, Jun 22, 2021 at 6:35 AM 'Fritz Elfert' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> On 22.06.21 12:01, Oleg Nenashev wrote:
> > Hi all,
> >
> > I am currently updating roadmap and the Jenkins website to reference the
> initiative and contributing.
> > To group everything and to coordinate contributions, I have created a
> Discourse topic here:
> https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180
> <
> https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180>
>  .
> I will be using it as a main source of contributing guidelines. Please feel
> free to contribute!
>
> What is still unclear to me (asked you in
> https://issues.jenkins.io/browse/JENKINS-62833) but no answer yet):
> Does this also include java class names or only user-visible
> text/messages/doc?
>
> Thanks
>   -Fritz
> >
> > Best regards,
> > Oleg Nenashev
> >
> > On Wednesday, May 19, 2021 at 8:36:41 PM UTC+2 db...@cloudbees.com
> wrote:
> >
> > On Wed, May 19, 2021 at 8:08 AM 'Gavin Mogan' via Jenkins Developers
>  wrote:
> >
> > I'm actually against updating the changelog. The changes to
> terminology were not done then, and by showing the old and the new, you
> show growth. I'm not a fan of rewriting history, even in git.
> >
> >
> > We're not "rewriting history" here. You wouldn't leave some wrong
> formatting around after migrating a file from Markdown to Asciidoc (or vice
> versa). You'd fix old typos. You'd adapt old links when the URL of the
> pages they point to change. And if we change the words we use to refer to
> something, that applies retroactively as well.
> >
> > --
> > 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  jenkinsci-dev+unsubscr...@googlegroups.com>.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/bdbaa768-fcf4-45d1-924d-52be07a39c88n%40googlegroups.com
> <
> https://groups.google.com/d/msgid/jenkinsci-dev/bdbaa768-fcf4-45d1-924d-52be07a39c88n%40googlegroups.com?utm_medium=email_source=footer
> >.
>
> --
> 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/27bb0f2a-5995-d6a2-1f39-11aa1d6670cf%40fritz-elfert.de
> .
>

-- 
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/CAG%3D_DusJ-2QmVF2xsuLRzoFi3GG5KsNtv%3DEz2rBUNCwNbMeb%3DQ%40mail.gmail.com.

Adding groups from a second source?

[Michael Carter]

Basically I want to setup employee hierarchy groups as there's some 
permissions we want to grant based on who they work for.

The hierarchy is stored in a DB table and it isn't possible to get it added 
to SAML/SSO as a "Group".   Been trying that route from 2020 to no avail.

Can someone point me at the extension points or libraries which I could 
potentially add "groups" from a second, and/or third source(FYI: did 
looked at Role Based stragegy but for various reason we need to stick with 
"Project-based Matrix Authorization Strategy" so custom roles managed via 
script is out of the question)

Thanks.

-- 
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/169e8392-76cf-4d27-a21b-5219cde3c1b4n%40googlegroups.com.

Re: Proposal: Changing the Contributor License Agreement Process

[Oleg Nenashev]

Hi Tim. I would not like to enforce it for the Jenkins core and components 
until we have all active core maintainers and company contributors to sign 
ICLA/CCLA. It may take months. What I want to do is to enable EasyCLA 
without enforcement. So I need a few repositories where we could enable 
EasyCLA so that everyone can prepare.

I suggest the following repositories:

   - https://github.com/jenkinsci/infra-cla - good repo for testing CLA. 
   Everyone can submit PR with removing dated CLAs while verifying their 
   signatures in the process :)
   - platformlabeler-plugin and the elastic-axis-plugin as suggested by Mark
   - https://github.com/jenkinsci/custom-war-packager - not actively 
   developed at the moment
   - https://github.com/jenkinsci/label-verifier-plugin - not actively 
   developed at the moment
   
Is everyone fine with the ICLA/CCLA text? There are some minor differences 
from the current ICLA/CCLAs we use

BR, Oleg




On Tuesday, June 22, 2021 at 11:00:31 PM UTC+2 timja...@gmail.com wrote:

> Is this close enough for a vote? Do we actually want to do this?
>
> Moving the CLA process away from the current process sure, but enabling it 
> on Jenkins core?
>
> On Tue, 22 Jun 2021 at 21:12, Mark Waite  wrote:
>
>> Those all sound great to me.
>>
>> I volunteer the platformlabeler-plugin and the elastic-axis-plugin as two 
>> that could be used for testing if needed.
>>
>> Mark Waite
>>
>> On Tue, Jun 22, 2021 at 12:44 PM Oleg Nenashev  
>> wrote:
>>
>>> Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the 
>>> EasyCLA process on the 
>>> https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.
>>> We have reported a few minor issues discovered during testing, but 
>>> overall the process works pretty well.
>>>
>>> I suggest going ahead and enabling individual CLAs for a number of 
>>> repositories within jenkinsci. I suggest taking peripheral repos, because 
>>> we need to figure out company CLAs and have all key maintainer permissions 
>>> before enabling EasyCLA for the Jenkins core. 
>>>
>>> I suggest voting for enabling Easy CLA in the Jenkins core next week
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Tuesday, June 8, 2021 at 9:13:36 AM UTC+2 Oleg Nenashev wrote:
>>>
 Hi all,

 Just a quick update on the pending project:

- At the Governance meeting in April we agreed to proceed with 
exploring EasyCLA
- We submitted a request to the Linux Foundation. After several 
iterations, we agreed to keep EasyCLA management as a part of the CDF 
account for now. It technically allows all individuals and contributor 
companies to sign a single CLA for all projects, and then moderate 
 where 
they contribute by company CLA and internal guidelines
- I have got an access yesterday so that I am able to configure 
EasyCLA for Jenkins
- I set up a test repository in 
https://github.com/jenkinsci-infra-ircbot-test/test-easycla and 
enabled EasyCLA for it. I also enabled branch protection there, and it 
works well. Anyone welcome to try out the new process by submitting 
 pull 
requests to the repository.

 I will proceed with a process JEP to document the current state. Any 
 feedback is welcome!

 Best regards,
 Oleg


 On Thursday, April 8, 2021 at 8:00:14 PM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> Just in case, you can find some notes from the EasyCLA webinar and 
> Jenkins-specific questions from the webinar here 
> 
> .
> Slides and the Video will be published soon by the Linux Foundation.
>
> Best regards,
> Oleg
>
>
> On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:
>
>> Hi all,
>>
>> Quick progress update:
>>
>>- I have reached out to the Linux Foundation legal to clarify the 
>>CLA requirements. At the moment there is no strict guidelines how 
>> projects 
>>should use CLA/DCO, and there are projects using neither of them. 
>> Apart 
>>from the potential legal risks (e.g. MIT License does not cover 
>> patent 
>>grant listed in our CLA for the submitted code), the Jenkins 
>> community can 
>>proceed as is.
>>- I plan to setup the EasyCLA PoC so that the current 
>>contributors could try it out and see whether the process is 
>> convenient 
>>enough. Then we can discuss changes in the CLA policy.
>>- I have submitted an application form to create a Jenkins 
>>account on Easy CLA. Once it is created, I will share the permissions 
>> with 
>>the Jenkins governance board members
>>
>> For your information, there will be also a webinar about EasyCLA on 
>> April 8th: 

Re: Proposal: Changing the Contributor License Agreement Process

[Tim Jacomb]

Is this close enough for a vote? Do we actually want to do this?

Moving the CLA process away from the current process sure, but enabling it
on Jenkins core?

On Tue, 22 Jun 2021 at 21:12, Mark Waite  wrote:

> Those all sound great to me.
>
> I volunteer the platformlabeler-plugin and the elastic-axis-plugin as two
> that could be used for testing if needed.
>
> Mark Waite
>
> On Tue, Jun 22, 2021 at 12:44 PM Oleg Nenashev 
> wrote:
>
>> Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the
>> EasyCLA process on the
>> https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.
>> We have reported a few minor issues discovered during testing, but
>> overall the process works pretty well.
>>
>> I suggest going ahead and enabling individual CLAs for a number of
>> repositories within jenkinsci. I suggest taking peripheral repos, because
>> we need to figure out company CLAs and have all key maintainer permissions
>> before enabling EasyCLA for the Jenkins core.
>>
>> I suggest voting for enabling Easy CLA in the Jenkins core next week
>>
>> Best regards,
>> Oleg
>>
>>
>> On Tuesday, June 8, 2021 at 9:13:36 AM UTC+2 Oleg Nenashev wrote:
>>
>>> Hi all,
>>>
>>> Just a quick update on the pending project:
>>>
>>>- At the Governance meeting in April we agreed to proceed with
>>>exploring EasyCLA
>>>- We submitted a request to the Linux Foundation. After several
>>>iterations, we agreed to keep EasyCLA management as a part of the CDF
>>>account for now. It technically allows all individuals and contributor
>>>companies to sign a single CLA for all projects, and then moderate where
>>>they contribute by company CLA and internal guidelines
>>>- I have got an access yesterday so that I am able to configure
>>>EasyCLA for Jenkins
>>>- I set up a test repository in
>>>https://github.com/jenkinsci-infra-ircbot-test/test-easycla and
>>>enabled EasyCLA for it. I also enabled branch protection there, and it
>>>works well. Anyone welcome to try out the new process by submitting pull
>>>requests to the repository.
>>>
>>> I will proceed with a process JEP to document the current state. Any
>>> feedback is welcome!
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Thursday, April 8, 2021 at 8:00:14 PM UTC+2 Oleg Nenashev wrote:
>>>
 Hi all,

 Just in case, you can find some notes from the EasyCLA webinar and
 Jenkins-specific questions from the webinar here
 
 .
 Slides and the Video will be published soon by the Linux Foundation.

 Best regards,
 Oleg


 On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> Quick progress update:
>
>- I have reached out to the Linux Foundation legal to clarify the
>CLA requirements. At the moment there is no strict guidelines how 
> projects
>should use CLA/DCO, and there are projects using neither of them. Apart
>from the potential legal risks (e.g. MIT License does not cover patent
>grant listed in our CLA for the submitted code), the Jenkins community 
> can
>proceed as is.
>- I plan to setup the EasyCLA PoC so that the current contributors
>could try it out and see whether the process is convenient enough. 
> Then we
>can discuss changes in the CLA policy.
>- I have submitted an application form to create a Jenkins account
>on Easy CLA. Once it is created, I will share the permissions with the
>Jenkins governance board members
>
> For your information, there will be also a webinar about EasyCLA on
> April 8th:
> https://linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/
> . It could be a good venue to ask any questions or to share our feedback.
>
> Best regards,
> Oleg Nenashev
>
>
>
> On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:
>
>> Thanks for the insights Andrew!
>>
>> I agree that DCO could be a good compromise for the Jenkins core and
>> related repositories.
>> I am not sure about plugin repositories, I'd guess we should make it
>> optional though recommended for the repositories.
>>
>> Best regards,
>> Oleg Nenashev
>>
>>
>>
>> On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <
>> agri...@linuxfoundation.org> wrote:
>>
>>> On 3/23/21 2:54 PM, Oleg Nenashev wrote:
>>> >> I don’t think that we should go this way. Kohsuke always tried to
>>> keep
>>> > the barrier for contributions very low and I think we should
>>> continue
>>> > this way. I think that we would not have so many plugins (or PRs
>>> for
>>> > plugins) if we make the contribution process more complex
>>> >
>>> > I would prefer to avoid 

Re: how to return some values to the caller of the Jenkins plugin

[Ullrich Hafner]

Am 22.06.2021 um 19:34 schrieb long song :
> 
> hi Ullrich,
> 
> In my actual use case, I don't just print it out, but need to call other APIs 
> with the result value.
> 
> Thanks for your suggestion. I will have a try to implement 
> the"org.jenkinsci.plugins.workflow.steps.Step"


Then this is the wrong approach. Either call the API from your plugin or store 
the results in an object that is controlled by Jenkins (Action).

> 
> best regards,
> Long
> 
> On Mon, Jun 21, 2021 at 1:42 AM Ullrich Hafner  > wrote:
> 
> 
>> Am 21.06.2021 um 00:52 schrieb long song > >:
>> 
>> 
>> Here is how I use the plugin the pipeline script
>> 
>> steps {
>>  script {
>> def myResult = MyPlugin Parameter1: value1, Parameter2: 
>> value2
>> println "$myResult"  
>>  }
>>  }
>> 
>> I expect to return a Json string or a map object which can contain running 
>> status such as "repo: xxx, version: xxx, total incidents: xxx ..."
>> 
> 
> Is your real requirement just to print out a structured text? Then use the 
> Jenkins logger in your BuildStep. Then you don’t need a return value. 
> 
>> Are you talking about the interface hudson.tasks.BuildStep ?
> 
> No, this could be done with a  `org.jenkinsci.plugins.workflow.steps.Step`
> 
> 
>> It returns a boolean but can't transport much infor. 
>> 
>> boolean perform(AbstractBuild build, Launcher launcher, BuildListener 
>> listener) throws InterruptedException, IOException;
>> 
>> To get the running result, I am thinking to store the running result as an 
>> artifact and parse it out after running MyPlugin.
>> 
> 
> 
> This still looks too complicated. Use the Tell-Don't-Ask principle 
> (https://martinfowler.com/bliki/TellDontAsk.html 
> )
> 
> Tell your Jenkins plugin what it should display and do not get values and 
> work with these values. 
> 
> 
>> Do you have some good practice that I can receive the running result from 
>> the Jenkins Plugin ?
>> 
>> Thanks!
>> 
>> On Sun, Jun 20, 2021 at 6:24 AM Ullrich Hafner > > wrote:
>> It is possible to return values from a step (but not from a SimpleBuildStep) 
>> 
>> Before I go into details we need to make sure that this approach makes 
>> senes, your requirements are not clear: 
>> - What is in the value that you want to return? 
>> - Why do you want to return a value? 
>> - What do you want to do with the value?
>> 
>>> Am 19.06.2021 um 02:05 schrieb long song >> >:
>>> 
>>> Hi,
>>> 
>>> Is there a way that I can receive a string value from running a Jenkins 
>>> plugin in the Jenkins pipeline script ?
>>> 
>>> // the myResult is always null after running the Jenkins plugin "MyPlugin"
>>> pipeline {
>>>agent any
>>>stages {
>>>   stage('MyPlugin: MyPlugin Run') {
>>>  steps {
>>>  script {
>>> def myResult = MyPlugin Parameter1: value1, Parameter2: 
>>> value2
>>> println "$myResult"  
>>>  }
>>>  }
>>>   }
>>>}
>>> 
>>> Here is the MyPlugin implementation.
>>> 
>>> public class MyPluginBuilder extends Builder implements SimpleBuildStep {
>>>  @Override
>>>  public void perform(@Nonnull Run run, @Nonnull FilePath 
>>> workspace, @Nonnull Launcher launcher, @Nonnull TaskListener listener) 
>>> throws IOException, InterruptedException { ... }
>>> }
>>> 
>>> The return type of the method perform() is void.
>>> 
>>> By design, Jenkins doesn't want to return anything back.
>>> 
>>> To get the running result, I am thinking to store the running result as an 
>>> artifact and parse it out after running MyPlugin.
>>> 
>>> Do you have some good practice that I can receive the running result from 
>>> the Jenkins Plugin ?
>>> 
>>> Thanks !
>>> Long
>>> 
>>> -- 
>>> 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/CANDLextj0bbX4zwToHLYCFU4EuYMUQYd0r_6NxWNVszKToDVbw%40mail.gmail.com
>>>  
>>> .
>> 
>> 
>> -- 
>> 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 
>> 

Re: Proposal: Changing the Contributor License Agreement Process

[Mark Waite]

Those all sound great to me.

I volunteer the platformlabeler-plugin and the elastic-axis-plugin as two
that could be used for testing if needed.

Mark Waite

On Tue, Jun 22, 2021 at 12:44 PM Oleg Nenashev 
wrote:

> Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the
> EasyCLA process on the
> https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.
> We have reported a few minor issues discovered during testing, but overall
> the process works pretty well.
>
> I suggest going ahead and enabling individual CLAs for a number of
> repositories within jenkinsci. I suggest taking peripheral repos, because
> we need to figure out company CLAs and have all key maintainer permissions
> before enabling EasyCLA for the Jenkins core.
>
> I suggest voting for enabling Easy CLA in the Jenkins core next week
>
> Best regards,
> Oleg
>
>
> On Tuesday, June 8, 2021 at 9:13:36 AM UTC+2 Oleg Nenashev wrote:
>
>> Hi all,
>>
>> Just a quick update on the pending project:
>>
>>- At the Governance meeting in April we agreed to proceed with
>>exploring EasyCLA
>>- We submitted a request to the Linux Foundation. After several
>>iterations, we agreed to keep EasyCLA management as a part of the CDF
>>account for now. It technically allows all individuals and contributor
>>companies to sign a single CLA for all projects, and then moderate where
>>they contribute by company CLA and internal guidelines
>>- I have got an access yesterday so that I am able to configure
>>EasyCLA for Jenkins
>>- I set up a test repository in
>>https://github.com/jenkinsci-infra-ircbot-test/test-easycla and
>>enabled EasyCLA for it. I also enabled branch protection there, and it
>>works well. Anyone welcome to try out the new process by submitting pull
>>requests to the repository.
>>
>> I will proceed with a process JEP to document the current state. Any
>> feedback is welcome!
>>
>> Best regards,
>> Oleg
>>
>>
>> On Thursday, April 8, 2021 at 8:00:14 PM UTC+2 Oleg Nenashev wrote:
>>
>>> Hi all,
>>>
>>> Just in case, you can find some notes from the EasyCLA webinar and
>>> Jenkins-specific questions from the webinar here
>>> 
>>> .
>>> Slides and the Video will be published soon by the Linux Foundation.
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:
>>>
 Hi all,

 Quick progress update:

- I have reached out to the Linux Foundation legal to clarify the
CLA requirements. At the moment there is no strict guidelines how 
 projects
should use CLA/DCO, and there are projects using neither of them. Apart
from the potential legal risks (e.g. MIT License does not cover patent
grant listed in our CLA for the submitted code), the Jenkins community 
 can
proceed as is.
- I plan to setup the EasyCLA PoC so that the current contributors
could try it out and see whether the process is convenient enough. Then 
 we
can discuss changes in the CLA policy.
- I have submitted an application form to create a Jenkins account
on Easy CLA. Once it is created, I will share the permissions with the
Jenkins governance board members

 For your information, there will be also a webinar about EasyCLA on
 April 8th:
 https://linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/
 . It could be a good venue to ask any questions or to share our feedback.

 Best regards,
 Oleg Nenashev



 On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:

> Thanks for the insights Andrew!
>
> I agree that DCO could be a good compromise for the Jenkins core and
> related repositories.
> I am not sure about plugin repositories, I'd guess we should make it
> optional though recommended for the repositories.
>
> Best regards,
> Oleg Nenashev
>
>
>
> On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <
> agri...@linuxfoundation.org> wrote:
>
>> On 3/23/21 2:54 PM, Oleg Nenashev wrote:
>> >> I don’t think that we should go this way. Kohsuke always tried to
>> keep
>> > the barrier for contributions very low and I think we should
>> continue
>> > this way. I think that we would not have so many plugins (or PRs for
>> > plugins) if we make the contribution process more complex
>> >
>> > I would prefer to avoid setting extra boundaries as well. At the
>> same
>> > time, it makes sense to review the current model with the LF legal
>> team.
>> > Right now we indeed avoid the contribution obstacles, but
>> effectively
>> > common code contributors and plugin maintainers do not sign CLA. It
>> may
>> > cause some legal 

Re: Proposal: Changing the Contributor License Agreement Process

[Oleg Nenashev]

Thanks to Justin Harringa, Mark Waite and Coleen Waite for testing the 
EasyCLA process on the 
https://github.com/jenkinsci-infra-ircbot-test/test-easycla  repository.
We have reported a few minor issues discovered during testing, but overall 
the process works pretty well.

I suggest going ahead and enabling individual CLAs for a number of 
repositories within jenkinsci. I suggest taking peripheral repos, because 
we need to figure out company CLAs and have all key maintainer permissions 
before enabling EasyCLA for the Jenkins core. 

I suggest voting for enabling Easy CLA in the Jenkins core next week

Best regards,
Oleg


On Tuesday, June 8, 2021 at 9:13:36 AM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> Just a quick update on the pending project:
>
>- At the Governance meeting in April we agreed to proceed with 
>exploring EasyCLA
>- We submitted a request to the Linux Foundation. After several 
>iterations, we agreed to keep EasyCLA management as a part of the CDF 
>account for now. It technically allows all individuals and contributor 
>companies to sign a single CLA for all projects, and then moderate where 
>they contribute by company CLA and internal guidelines
>- I have got an access yesterday so that I am able to configure 
>EasyCLA for Jenkins
>- I set up a test repository in 
>https://github.com/jenkinsci-infra-ircbot-test/test-easycla and 
>enabled EasyCLA for it. I also enabled branch protection there, and it 
>works well. Anyone welcome to try out the new process by submitting pull 
>requests to the repository.
>
> I will proceed with a process JEP to document the current state. Any 
> feedback is welcome!
>
> Best regards,
> Oleg
>
>
> On Thursday, April 8, 2021 at 8:00:14 PM UTC+2 Oleg Nenashev wrote:
>
>> Hi all,
>>
>> Just in case, you can find some notes from the EasyCLA webinar and 
>> Jenkins-specific questions from the webinar here 
>> 
>> .
>> Slides and the Video will be published soon by the Linux Foundation.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Friday, April 2, 2021 at 4:12:31 PM UTC+2 Oleg Nenashev wrote:
>>
>>> Hi all,
>>>
>>> Quick progress update:
>>>
>>>- I have reached out to the Linux Foundation legal to clarify the 
>>>CLA requirements. At the moment there is no strict guidelines how 
>>> projects 
>>>should use CLA/DCO, and there are projects using neither of them. Apart 
>>>from the potential legal risks (e.g. MIT License does not cover patent 
>>>grant listed in our CLA for the submitted code), the Jenkins community 
>>> can 
>>>proceed as is.
>>>- I plan to setup the EasyCLA PoC so that the current contributors 
>>>could try it out and see whether the process is convenient enough. Then 
>>> we 
>>>can discuss changes in the CLA policy.
>>>- I have submitted an application form to create a Jenkins account 
>>>on Easy CLA. Once it is created, I will share the permissions with the 
>>>Jenkins governance board members
>>>
>>> For your information, there will be also a webinar about EasyCLA on 
>>> April 8th: 
>>> https://linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/
>>>  
>>> . It could be a good venue to ask any questions or to share our feedback.
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>>
>>>
>>> On Wednesday, March 24, 2021 at 8:11:05 AM UTC+1 Oleg Nenashev wrote:
>>>
 Thanks for the insights Andrew!

 I agree that DCO could be a good compromise for the Jenkins core and 
 related repositories.
 I am not sure about plugin repositories, I'd guess we should make it 
 optional though recommended for the repositories.

 Best regards,
 Oleg Nenashev



 On Tue, Mar 23, 2021, 23:10 Andrew Grimberg <
 agri...@linuxfoundation.org> wrote:

> On 3/23/21 2:54 PM, Oleg Nenashev wrote:
> >> I don’t think that we should go this way. Kohsuke always tried to 
> keep
> > the barrier for contributions very low and I think we should continue
> > this way. I think that we would not have so many plugins (or PRs for
> > plugins) if we make the contribution process more complex
> > 
> > I would prefer to avoid setting extra boundaries as well. At the same
> > time, it makes sense to review the current model with the LF legal 
> team.
> > Right now we indeed avoid the contribution obstacles, but effectively
> > common code contributors and plugin maintainers do not sign CLA. It 
> may
> > cause some legal loopholes, especially in the terms of the patent 
> right
> > which is not covered by the MIT License used in Jenkins. Not that I
> > expect any real issues with that, but maybe there is a way to be on 
> the
> > safe side with minimum impact on contributors.
>
> I'm not legal council for LF, but since I do 

Re: how to return some values to the caller of the Jenkins plugin

[long song]

hi Jesse,

Thank you for the input.

Defining environment variables should be a good solution for my case.

thanks!
Long


On Mon, Jun 21, 2021 at 9:29 AM Jesse Glick  wrote:

> Beware that returning a value from a `Step` means that your step cannot be
> used naturally in Declarative Pipeline (only by “cheating” with a `script`
> block). If values need to be passed to other parts of a build, it may be
> better to use a block-scoped step and define environment variables (this
> can be done either in a first-class `Step` or in a `SimpleBuildWrapper`),
> though that assumes plain `String`s rather than structured objects:
>
> yourPlugin(param1: 'one', param2: 'two') {
>   sh 'echo using $VERSION from $REPO'
> }
>
> --
> 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/CANfRfr0XBMiy-%2BHwnVZCB6GRLym8oeUZ%3DpM0f5Q5mhxgK3rE3g%40mail.gmail.com
> 
> .
>

-- 
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/CANDLext%2BDX-PZqCxwySacU4jDDCmQ9yNJ56ZdzBZ%2BDDRufhxew%40mail.gmail.com.

Re: how to return some values to the caller of the Jenkins plugin

[long song]

hi Ullrich,

In my actual use case, I don't just print it out, but need to call other
APIs with the result value.

Thanks for your suggestion. I will have a try to implement the
"org.jenkinsci.plugins.workflow.steps.Step"

best regards,
Long

On Mon, Jun 21, 2021 at 1:42 AM Ullrich Hafner 
wrote:

>
>
> Am 21.06.2021 um 00:52 schrieb long song :
>
>
> Here is how I use the plugin the pipeline script
>
> steps {
>  script {
> def myResult = MyPlugin Parameter1: value1, Parameter2:
> value2
> println "$myResult"
>  }
>  }
>
> I expect to return a Json string or a map object which can contain running
> status such as "repo: xxx, version: xxx, total incidents: xxx ..."
>
>
> Is your real requirement just to print out a structured text? Then use the
> Jenkins logger in your BuildStep. Then you don’t need a return value.
>
> Are you talking about the interface hudson.tasks.BuildStep ?
>
>
> No, this could be done with a  `org.jenkinsci.plugins.workflow.steps.Step`
>
>
> It returns a boolean but can't transport much infor.
>
> boolean perform(AbstractBuild build, Launcher launcher, BuildListener
> listener) throws InterruptedException, IOException;
>
> To get the running result, I am thinking to store the running result as an
> artifact and parse it out after running MyPlugin.
>
>
>
> This still looks too complicated. Use the Tell-Don't-Ask principle (
> https://martinfowler.com/bliki/TellDontAsk.html)
>
> Tell your Jenkins plugin what it should display and do not get values and
> work with these values.
>
>
> Do you have some good practice that I can receive the running result from
> the Jenkins Plugin ?
>
> Thanks!
>
> On Sun, Jun 20, 2021 at 6:24 AM Ullrich Hafner 
> wrote:
>
>> It is possible to return values from a step (but not from a
>> SimpleBuildStep)
>>
>> Before I go into details we need to make sure that this approach makes
>> senes, your requirements are not clear:
>> - What is in the value that you want to return?
>> - Why do you want to return a value?
>> - What do you want to do with the value?
>>
>> Am 19.06.2021 um 02:05 schrieb long song :
>>
>> Hi,
>>
>> Is there a way that I can receive a string value from running a Jenkins
>> plugin in the Jenkins pipeline script ?
>>
>> // the myResult is always null after running the Jenkins plugin "MyPlugin"
>> pipeline {
>>agent any
>>stages {
>>   stage('MyPlugin: MyPlugin Run') {
>>  steps {
>>  script {
>> def myResult = MyPlugin Parameter1: value1, Parameter2:
>> value2
>> println "$myResult"
>>  }
>>  }
>>   }
>>}
>>
>> Here is the MyPlugin implementation.
>>
>> public class MyPluginBuilder extends Builder implements SimpleBuildStep {
>>  @Override
>>  public void perform(@Nonnull Run run, @Nonnull FilePath
>> workspace, @Nonnull Launcher launcher, @Nonnull TaskListener listener)
>> throws IOException, InterruptedException { ... }
>> }
>>
>> The return type of the method perform() is void.
>>
>> By design, Jenkins doesn't want to return anything back.
>>
>> To get the running result, I am thinking to store the running result as
>> an artifact and parse it out after running MyPlugin.
>>
>> Do you have some good practice that I can receive the running result from
>> the Jenkins Plugin ?
>>
>> Thanks !
>> Long
>>
>> --
>> 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/CANDLextj0bbX4zwToHLYCFU4EuYMUQYd0r_6NxWNVszKToDVbw%40mail.gmail.com
>> 
>> .
>>
>>
>>
>> --
>> 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/DB6814A1-964E-40B2-B048-595D967EA10F%40gmail.com
>> 
>> .
>>
>
> --
> 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/CANDLexvYg2nmA_0StJ_%2BCXBLDzyRE0NwNWCgcWGMPGnU4pPBzg%40mail.gmail.com
> 

Re: Question regarding the one shot workers to be gracefully terminated

[Jesse Glick]

On Tue, Jun 22, 2021 at 12:28 PM Victor Martinez <
victormartinezru...@gmail.com> wrote:

> *INFO hudson.remoting.Request$2#run: Failed to send back a reply to the
> request hudson.remoting.Request$2@…:
> hudson.remoting.ChannelClosedException: Channel
> "hudson.remoting.Channel@…": channel is already closed*
>
If you can reproduce your warning, please try with
https://github.com/jenkinsci/remoting/pull/463 to see what exactly the
`Request` is and whether my `TODO` comment would help.

-- 
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/CANfRfr1REL25P0%2Bc1QHTX9M-xYWq%3D1UGppOg7_QAJQDK_EsRqQ%40mail.gmail.com.

Question regarding the one shot workers to be gracefully terminated

[Victor Martinez]

Hi all,

When using the Google Compute Engine plugin with `oneShot` workers, I see 
some stacktraces with the below error message.

*2021-06-22 16:09:45.264+ [id=497] INFO 
o.j.p.workflow.job.WorkflowRun#finish: hello-world-gce #9 completed: 
SUCCESS*

*2021-06-22 16:09:45.936+ [id=497] INFO hudson.remoting.Request$2#run: 
Failed to send back a reply to the request 
hudson.remoting.Request$2@67760e47: hudson.remoting.ChannelClosedException: 
Channel "hudson.remoting.Channel@c9422c06:obs11-ubuntu-18-linux-14sl9x": 
channel is already closed*

Therefore, the CloudProvisioningListener#onFailure 

 is 
executed even though the build did finish successfully.

As far as I see the Google Compute Engine uses the OnceRetentionStrategy 

 when 
the task has finished and therefore the taskCompleted 

 is 
executed for the AbstractCloudSlave.

IIUC, the piece of stacktrace is caused by 
https://github.com/jenkinsci/jenkins/blob/862acf3e2d3fd48330a7326bd8901d82085244d6/core/src/main/java/hudson/slaves/NodeProvisioner.java#L235-L241

Question, what's the best approach to gracefully terminate the connection 
in the cloud providers? 

My aim, is to extend the CloudProvisioningListener class to monitor what 
cloud workers failed genuinely versus the ones that were killed gracefully?

Thanks



-- 
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/66beb562-b726-4a38-a607-2eac6e3e7208n%40googlegroups.com.

Re: Jenkins Terminology cleanup continued - sub-terms for controllers

['Fritz Elfert' via Jenkins Developers]

On 22.06.21 12:01, Oleg Nenashev wrote:

Hi all,

I am currently updating roadmap and the Jenkins website to reference the 
initiative and contributing.
To group everything and to coordinate contributions, I have created a Discourse topic 
here: 
https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180
 

 . I will be using it as a main source of contributing guidelines. Please feel free 
to contribute!


What is still unclear to me (asked you in 
https://issues.jenkins.io/browse/JENKINS-62833) but no answer yet):
Does this also include java class names or only user-visible text/messages/doc?

Thanks
 -Fritz


Best regards,
Oleg Nenashev

On Wednesday, May 19, 2021 at 8:36:41 PM UTC+2 db...@cloudbees.com wrote:

On Wed, May 19, 2021 at 8:08 AM 'Gavin Mogan' via Jenkins Developers 
 wrote:

I'm actually against updating the changelog. The changes to terminology 
were not done then, and by showing the old and the new, you show growth. I'm 
not a fan of rewriting history, even in git.


We're not "rewriting history" here. You wouldn't leave some wrong 
formatting around after migrating a file from Markdown to Asciidoc (or vice versa). You'd 
fix old typos. You'd adapt old links when the URL of the pages they point to change. And 
if we change the words we use to refer to something, that applies retroactively as well.

--
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/bdbaa768-fcf4-45d1-924d-52be07a39c88n%40googlegroups.com
 
.


--
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/27bb0f2a-5995-d6a2-1f39-11aa1d6670cf%40fritz-elfert.de.


OpenPGP_0x6E8338980332A6B0.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Jenkins Terminology cleanup continued - sub-terms for controllers

[Angélique Jard]

Hi everyone,

I am proposing a JEP to have all terms in a single place 
https://github.com/jenkinsci/jep/pull/368
My secret hope is to make it easy for new contributors or one day 
contributors (hacktahons, ...) to participate to the terminology update 
effort.
Feel free to join and/or to review this PR (and even more if you know other 
languages than English)

Angélique

On Tuesday, June 22, 2021 at 12:01:35 PM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> I am currently updating roadmap and the Jenkins website to reference the 
> initiative and contributing.
> To group everything and to coordinate contributions, I have created a 
> Discourse topic here: 
> https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180
>  . 
> I will be using it as a main source of contributing guidelines. Please feel 
> free to contribute!
>
> Best regards,
> Oleg Nenashev
>
> On Wednesday, May 19, 2021 at 8:36:41 PM UTC+2 db...@cloudbees.com wrote:
>
>> On Wed, May 19, 2021 at 8:08 AM 'Gavin Mogan' via Jenkins Developers <
>> jenkin...@googlegroups.com> wrote:
>>
>>> I'm actually against updating the changelog. The changes to terminology 
>>> were not done then, and by showing the old and the new, you show growth. 
>>> I'm not a fan of rewriting history, even in git.
>>>
>>
>> We're not "rewriting history" here. You wouldn't leave some wrong 
>> formatting around after migrating a file from Markdown to Asciidoc (or vice 
>> versa). You'd fix old typos. You'd adapt old links when the URL of the 
>> pages they point to change. And if we change the words we use to refer to 
>> something, that applies retroactively as well.
>>
>

-- 
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/153a750b-91db-4634-b2d9-99884fa0f3b1n%40googlegroups.com.

Re: Jenkins Terminology cleanup continued - sub-terms for controllers

[Oleg Nenashev]

Hi all,

I am currently updating roadmap and the Jenkins website to reference the 
initiative and contributing.
To group everything and to coordinate contributions, I have created a 
Discourse topic here: 
https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180
 . 
I will be using it as a main source of contributing guidelines. Please feel 
free to contribute!

Best regards,
Oleg Nenashev

On Wednesday, May 19, 2021 at 8:36:41 PM UTC+2 db...@cloudbees.com wrote:

> On Wed, May 19, 2021 at 8:08 AM 'Gavin Mogan' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
>
>> I'm actually against updating the changelog. The changes to terminology 
>> were not done then, and by showing the old and the new, you show growth. 
>> I'm not a fan of rewriting history, even in git.
>>
>
> We're not "rewriting history" here. You wouldn't leave some wrong 
> formatting around after migrating a file from Markdown to Asciidoc (or vice 
> versa). You'd fix old typos. You'd adapt old links when the URL of the 
> pages they point to change. And if we change the words we use to refer to 
> something, that applies retroactively as well.
>

-- 
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/bdbaa768-fcf4-45d1-924d-52be07a39c88n%40googlegroups.com.

Re: Terminology Updates

[Oleg Nenashev]

Hi all,

I am currently updating roadmap and the Jenkins website to reference the 
initiative and contributing.
To group everything and to coordinate contributions, I have created a 
Discourse topic 
here: 
https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180
 
. I will be using it as a main source of contributing guidelines. Please 
feel free to contribute!

Best regards,
Oleg Nenashev

On Tuesday, April 20, 2021 at 3:31:08 PM UTC+2 Oleg Nenashev wrote:

> Hi all,
>
> Just a quick update, I have created 
> https://groups.google.com/u/1/g/jenkinsci-dev/c/x5vdlJDvntw to follow-up 
> on selecting terms for controller sub-instances like web interface or the 
> "primary" node used for runs. Any feedback will be appreciated: 
> https://groups.google.com/u/1/g/jenkinsci-dev/c/x5vdlJDvntw 
>
> Best regards,
> Oleg
>  
>
> On Thursday, August 13, 2020 at 2:58:34 PM UTC+2 slide wrote:
>
>> Hi everyone,
>>
>> To follow up on the Governance Meeting (
>> https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.10x94wjx4rlj).
>>  
>> We took the input from the community poll and discussed the options. We 
>> voted to change from the term "master' to the term "controller" in 
>> referring to the "Jenkins Application". We will be doing some additional 
>> work to understand the internationalization aspects as people start to make 
>> PR's to change terms in non-english languages. I will be creating a page 
>> that will contain recommendations for each language for various terms as 
>> the various language discussions occur during PR's. 
>>
>> Thanks for all those who participated in the poll and the discussion.
>>
>> Regards,
>>
>> Alex
>>
>> On Wednesday, August 12, 2020 at 10:55:07 AM UTC-7 Oleg Nenashev wrote:
>>
>>> Hi all,
>>>
>>> Just a reminder, we will be selecting a final term at the governance 
>>> meeting in 5 minutes.
>>> Everybody is welcome to participate: 
>>> https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Thursday, July 30, 2020 at 7:21:19 PM UTC+2, slide wrote:

 Hi Everyone,

 Just wanted to update on the current status of this effort. We 
 discussed this in the Governance Meeting yesterday. The poll closed 
 yesterday, you can see the results at: 
 https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1bd92a17371a1ca5. 
 They are also shown below:

 Result
 1. *Controller*  (Condorcet winner: wins contests with all other 
 choices)
 2. Manager  loses to Controller by 95–35
 3. Coordinator  loses to Controller by 98–37, loses to Manager by 69–59
 4. Primary  loses to Controller by 90–44, loses to Coordinator by 66–63
 5. Main  loses to Controller by 97–36, loses to Primary by 68–47
 6. Director  loses to Controller by 110–21, loses to Main by 70–56
 7. Leader  loses to Controller by 106–24, loses to Director by 71–46
 8. Executive  loses to Controller by 116–15, loses to Leader by 65–34

 Our plan now is to take the terms from the poll and run them through 
 some checks with native speakers and Google Translate to check the 
 internationalization aspects of the options. We will make a final decision 
 in the next Governance Meeting and make announcements here on the 
 Developers Mailing List as well as providing context and information via 
 blog posts.

 Just as a reminder, this effort is to replace the "Jenkins application" 
 term, for what used to be termed the "Jenkins Master." In addition to this 
 usage of "master" we also have the concept of the "master" node that can 
 exist in the Jenkins Application. We will determine next steps on 
 replacing 
 that term (for that node) in the future (because the terms in the list 
 below do not necessarily match the requirements in the context of nodes). 

 We want to thank everyone who participated in the poll. We are working 
 hard to get these changes going on this important effort.

 Regards,

 Alex Earl

 On Wednesday, July 29, 2020 at 10:38:24 AM UTC-7 Oleg Nenashev wrote:

> Thanks to everyone who voted for the options! We will review of the 
> voting results to the Governance meeting agenda: 
> https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.cgd8zbewht8o
>
> The meeting will start in 20 minutes, everyone is welcome to join: 
> https://zoom.us/j/99217163913?pwd=TldwZWZTQzNNc3ZGaThFOThlckFGQT09
>
> Best regards,
> Oleg
>
>
> On Thursday, July 23, 2020 at 8:35:15 PM UTC+2, Mark Waite wrote:
>
>> Unfortunately, new terms can't be included in the the votiing.  The 
>> voting is already in progress at  
>> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_1bd92a17371a1ca5=f82b79a50f54ad87
>>  .  
>> The governance board is using the 

Re: HELP NEEDED - Jenkins contributor summit on Jun 25

['Bartłomiej Antoniak' via Jenkins Developers]

Hi,

Sure, let's catch up there and discuss further plan.

Regards,
Bartek

wt., 22 cze 2021 o 11:01 Vibhav Bobade  napisał(a):

> Hi team, Olblak,
>
> That sounds like a good idea. @BartlomieJ I am available on the continuous
> delivery foundation slack if you would like to plan out the session. I will
> PM you there for now then, we can take it from there.
>
> Regards,
> Vibhav
>
>
> On Thu, 17 Jun, 2021, 5:09 pm Olblak,  wrote:
>
>> Hi Bartłomiej,
>>
>> That would be really great.
>> Vibhav is interested to present initiatives from the Coud Native SIG,
>> maybe you could sync with him for that part
>> The sig update is around 10min max and then we have more time in a later
>> session to go deeper on the jenkins kubernetes operator.
>>
>> I am adding your name on the schedule for the longer session, do you
>> already have an idea of how long you need?
>> Would 30 min work for you?
>>
>>
>>
>> On Thu, Jun 17, 2021, at 9:50 AM, 'Bartłomiej Antoniak' via Jenkins
>> Developers wrote:
>>
>> Hi all,
>>
>> I'm happy to take over Jenkins Kubernetes Operator part. The initial idea
>> was to present high-level update and further plans during opening session.
>> Then reserve a breakout session for the deep dive to particular topics
>> and longer discussion if needed.
>>
>> Regards,
>> Bartek
>>
>> śr., 16 cze 2021 o 13:28 'Olblak' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> napisał(a):
>>
>>
>> Same here, it makes the schedule easier from EU :p
>>
>> Because of the PDT timezone, I was thinking of the following topic order
>>
>> 1. Project update
>> 2. Contributor track, as this part heavily require participation from
>> attendees
>> 3. SIG  update
>> followed by all presentations such as unconference,etc.
>>
>> If we are on EDT, then it would make sense to swap Contributor track and
>> SIG update so
>> 1. Project Update
>> 2. SIG Update <- Seems more logical in terms of timeline
>> 3. Contributor Track <- This would be easier for folks from US West coast
>> to participate
>>  to the contributor track.
>>
>> I am curious what people from APAC would prefer?
>>
>> Again based on all the discussion I am having, I am still trying to
>> draft schedule here
>> 
>>
>>
>>
>>
>> On Wed, Jun 16, 2021, at 12:34 PM, Tim Jacomb wrote:
>>
>> If its east coast 9am I can help more / attend some sessions :)
>>
>> On Wed, 16 Jun 2021 at 11:02, Oleg Nenashev 
>> wrote:
>>
>> I think we can schedule it as we wish, we just need to announce it
>> timely. East Coast 9am is my strong preference
>>
>> On Wed, Jun 16, 2021, 11:53 'Olblak' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>
>> Hi Everybody,
>>
>> I think I am wrong since the beginning while working on the contributor
>> summit agenda. :(
>> Is the contributor summit supposed to start at 9AM PDT or 9AM EDT?
>> This is "slightly" different for session that would benefit from folks
>> from EU and US west coast
>>
>>
>> On Fri, Jun 11, 2021, at 9:46 PM, Baptiste Mathus wrote:
>>
>> I'm sorry to be so late on this... I am going to write here for
>> visibility, and I'll also add or see to add it correctly the sheet
>> initiated by Oleg.
>>
>> 1. I would like to help facilitate a conversation on Guava upgrade in
>> Jenkins Core.
>> As you know, this work is already somehow started. I'd like us to take
>> the summit opportunity to decide on next steps, approaches.
>> Our team at CloudBees is committed to help on this subject.
>>
>> 2. Plugin EOL policy // plugin maintenance status
>> I think these two subjects would serve us as a community to keep moving
>> Jenkins forward.
>> For the commons-digester:2.1 recent removal for instance, I think we
>> spent a subtantial amount of effort on plugins nobody should use anymore
>> since a long time.
>> If we had had such a policy, we could have saved a lot of energy together.
>>
>> 3. Company/team ownership for plugins
>> As an ex-HOSTING team member and a contributor since a few years, I think
>> we need to have a clearer stance for companies to implement a Jenkins
>> plugin for their software.
>> It happens regularly than a company, not intimate with the Jenkins
>> Project's governance, will request commit access to a plugin they think
>> they own somehow. (e.g. HOSTING-901, HOSTING-346, HOSTING-288, HOSTING-134,
>> and we could go on)
>> Only then they discover that from the Jenkins Project's standpoint, they
>> do not *exist*. An ex-employee that may have even left a given company
>> could disagree to let commit rights go and they would be entitled to this
>> (fortunately didn't happen yet, to my knowledge).
>>
>> The other case I've got in mind is the "team" concept. That's the one I'm
>> most interested in personally. For example, when people move between teams
>> in our company etc., we usually need to update many files in RPU and
>> request commit access in various repositories.
>> If we could have an 

Re: HELP NEEDED - Jenkins contributor summit on Jun 25

[Vibhav Bobade]

Hi team, Olblak,

That sounds like a good idea. @BartlomieJ I am available on the continuous
delivery foundation slack if you would like to plan out the session. I will
PM you there for now then, we can take it from there.

Regards,
Vibhav


On Thu, 17 Jun, 2021, 5:09 pm Olblak,  wrote:

> Hi Bartłomiej,
>
> That would be really great.
> Vibhav is interested to present initiatives from the Coud Native SIG,
> maybe you could sync with him for that part
> The sig update is around 10min max and then we have more time in a later
> session to go deeper on the jenkins kubernetes operator.
>
> I am adding your name on the schedule for the longer session, do you
> already have an idea of how long you need?
> Would 30 min work for you?
>
>
>
> On Thu, Jun 17, 2021, at 9:50 AM, 'Bartłomiej Antoniak' via Jenkins
> Developers wrote:
>
> Hi all,
>
> I'm happy to take over Jenkins Kubernetes Operator part. The initial idea
> was to present high-level update and further plans during opening session.
> Then reserve a breakout session for the deep dive to particular topics and
> longer discussion if needed.
>
> Regards,
> Bartek
>
> śr., 16 cze 2021 o 13:28 'Olblak' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> napisał(a):
>
>
> Same here, it makes the schedule easier from EU :p
>
> Because of the PDT timezone, I was thinking of the following topic order
>
> 1. Project update
> 2. Contributor track, as this part heavily require participation from
> attendees
> 3. SIG  update
> followed by all presentations such as unconference,etc.
>
> If we are on EDT, then it would make sense to swap Contributor track and
> SIG update so
> 1. Project Update
> 2. SIG Update <- Seems more logical in terms of timeline
> 3. Contributor Track <- This would be easier for folks from US West coast
> to participate
>  to the contributor track.
>
> I am curious what people from APAC would prefer?
>
> Again based on all the discussion I am having, I am still trying to  draft
> schedule here
> 
>
>
>
>
> On Wed, Jun 16, 2021, at 12:34 PM, Tim Jacomb wrote:
>
> If its east coast 9am I can help more / attend some sessions :)
>
> On Wed, 16 Jun 2021 at 11:02, Oleg Nenashev 
> wrote:
>
> I think we can schedule it as we wish, we just need to announce it timely.
> East Coast 9am is my strong preference
>
> On Wed, Jun 16, 2021, 11:53 'Olblak' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>
> Hi Everybody,
>
> I think I am wrong since the beginning while working on the contributor
> summit agenda. :(
> Is the contributor summit supposed to start at 9AM PDT or 9AM EDT?
> This is "slightly" different for session that would benefit from folks
> from EU and US west coast
>
>
> On Fri, Jun 11, 2021, at 9:46 PM, Baptiste Mathus wrote:
>
> I'm sorry to be so late on this... I am going to write here for
> visibility, and I'll also add or see to add it correctly the sheet
> initiated by Oleg.
>
> 1. I would like to help facilitate a conversation on Guava upgrade in
> Jenkins Core.
> As you know, this work is already somehow started. I'd like us to take the
> summit opportunity to decide on next steps, approaches.
> Our team at CloudBees is committed to help on this subject.
>
> 2. Plugin EOL policy // plugin maintenance status
> I think these two subjects would serve us as a community to keep moving
> Jenkins forward.
> For the commons-digester:2.1 recent removal for instance, I think we spent
> a subtantial amount of effort on plugins nobody should use anymore since a
> long time.
> If we had had such a policy, we could have saved a lot of energy together.
>
> 3. Company/team ownership for plugins
> As an ex-HOSTING team member and a contributor since a few years, I think
> we need to have a clearer stance for companies to implement a Jenkins
> plugin for their software.
> It happens regularly than a company, not intimate with the Jenkins
> Project's governance, will request commit access to a plugin they think
> they own somehow. (e.g. HOSTING-901, HOSTING-346, HOSTING-288, HOSTING-134,
> and we could go on)
> Only then they discover that from the Jenkins Project's standpoint, they
> do not *exist*. An ex-employee that may have even left a given company
> could disagree to let commit rights go and they would be entitled to this
> (fortunately didn't happen yet, to my knowledge).
>
> The other case I've got in mind is the "team" concept. That's the one I'm
> most interested in personally. For example, when people move between teams
> in our company etc., we usually need to update many files in RPU and
> request commit access in various repositories.
> If we could have an official concept for teams within the Jenkins Project,
> I think we could set up special GH teams (for example one for ours at
> CloudBees) + create possibly such a concept for it inside RPU to define
> this only once.
> I think this is already doable (we already 

Re: HELP NEEDED - Jenkins contributor summit on Jun 25

['Olblak' via Jenkins Developers]

Due to personal reasons, I won't be available for the contributor summit.


On Sat, Jun 19, 2021, at 10:39 AM, Oleg Nenashev wrote:
> Hi all,
> 
> I have created the #jenkins-contributor-summit channel in the Continuous 
> Delivery Foundation Slack workspace. Anyone is welcome to join and 
> participate in the organization, planning, and async conversation. How to 
> join the CDF Slack 
> .
>  I have also restructured the agenda in the coordination doc 
> 
>  based on the discussion we had last week. Landing page update: 
> https://github.com/jenkins-infra/jenkins.io/pull/4429
> 
> *On my availability*: Sadly, I cannot commit on my availability during, 
> before or after the summit. The Jenkins governance board and officers are 
> informed about the situation. Personal emergency. I will do my best to help 
> where I can and to prepare the State of the Union session. Will try to 
> deliver on other action items like end user panel. Olivier Vernin will be 
> taking over the overall summit coordination, together with other org team 
> members. Thanks a lot to Olivier! As always, everyone is invited to 
> participate and contribute! How to help? 
> 
> 
> *On Kubernetes operator.* Based on the separate conversation with Bartek, I 
> have added the breakout session of the operator. We also expect a short 
> 5-10min update during the State of The Union in the beginning of the summit.
> 
> Best regards,
> Oleg
> 
> On Thursday, June 17, 2021 at 1:39:08 PM UTC+2 Olblak wrote:
>> __
>> Hi Bartłomiej,
>> 
>> That would be really great. 
>> Vibhav is interested to present initiatives from the Coud Native SIG, maybe 
>> you could sync with him for that part
>> The sig update is around 10min max and then we have more time in a later 
>> session to go deeper on the jenkins kubernetes operator.
>> 
>> I am adding your name on the schedule for the longer session, do you already 
>> have an idea of how long you need?
>> Would 30 min work for you? 
>> 
>> 
>> 
>> On Thu, Jun 17, 2021, at 9:50 AM, 'Bartłomiej Antoniak' via Jenkins 
>> Developers wrote:
>>> Hi all,
>>> 
>>> I'm happy to take over Jenkins Kubernetes Operator part. The initial idea 
>>> was to present high-level update and further plans during opening session. 
>>> Then reserve a breakout session for the deep dive to particular topics and 
>>> longer discussion if needed.
>>> 
>>> Regards,
>>> Bartek
>>> 
>>> śr., 16 cze 2021 o 13:28 'Olblak' via Jenkins Developers 
>>>  napisał(a):
 __
 Same here, it makes the schedule easier from EU :p 
 
 Because of the PDT timezone, I was thinking of the following topic order
 
 1. Project update 
 2. Contributor track, as this part heavily require participation from 
 attendees
 3. SIG  update
 followed by all presentations such as unconference,etc.
 
 If we are on EDT, then it would make sense to swap Contributor track and 
 SIG update so 
 1. Project Update
 2. SIG Update <- Seems more logical in terms of timeline
 3. Contributor Track <- This would be easier for folks from US West coast 
 to participate
  to the contributor track. 
 
 I am curious what people from APAC would prefer?
 
 Again based on all the discussion I am having, I am still trying to  draft 
 schedule here 
 
 
 
 
 
 On Wed, Jun 16, 2021, at 12:34 PM, Tim Jacomb wrote:
> If its east coast 9am I can help more / attend some sessions :)
> 
> On Wed, 16 Jun 2021 at 11:02, Oleg Nenashev  wrote:
>> I think we can schedule it as we wish, we just need to announce it 
>> timely. East Coast 9am is my strong preference
>> 
>> On Wed, Jun 16, 2021, 11:53 'Olblak' via Jenkins Developers 
>>  wrote:
>>> __
>>> Hi Everybody,
>>> 
>>> I think I am wrong since the beginning while working on the contributor 
>>> summit agenda. :(
>>> Is the contributor summit supposed to start at 9AM PDT or 9AM EDT? 
>>> This is "slightly" different for session that would benefit from folks 
>>> from EU and US west coast
>>>  
>>> 
>>> On Fri, Jun 11, 2021, at 9:46 PM, Baptiste Mathus wrote:
 I'm sorry to be so late on this... I am going to write here for 
 visibility, and I'll also add or see to add it correctly the sheet 
 initiated by Oleg.
 
 1. I would like to help facilitate a conversation on Guava upgrade in 
 Jenkins Core.
 As you know, this work is already somehow started. I'd like us to take