Re: A new home for Jenkins

[Rick]

This would be huge good news for Jenkins community I think. Especially for
Jenkins China Community. I'm very looking forward to it. I think the CDF
could provide us with a great opportunity to host more events or
activities. I can image that CDF will help to bring more contributors and
sponsors into the community.

Second, I need to thank KK for giving me the support and delegation to
running Jenkins Subscription WeChat Account. Now we almost have 1K
subscribers. One article will be published per week. And I'm willing to
take the initiative to help build an activity Jenkins Community in China.
I'd love to the contact person in China for CDF or Jenkins if we need some
kind that people. I've serval Jenkins related talks at some conference or
meetup last year. I hope I could speak more topics to my forks this year.
My company (alauda.io) and other companies or communities (DevOpsDays) are
very supportive. I hope I could show up in the KubeCon in China this year.

If I understand correctly, we don't discuss the details in this thread. But
if everything is going well, then we might need to create a new
organization which named like CDF. An official website might be necessary
too. So, in my opinion, it will have lots of works are waiting for us.
Right?

Anyway, I expect more and more good news about Jenkins. If there's anything
I can do for the Jenkins community. Just say it.

Best regards,
Rick (Zhao Xiaojie)

On Thu, Jan 17, 2019 at 4:32 AM Oliver Gondža  wrote:

> Those are interesting news. Are we expecting to partner with existing
> communities around existing CD projects as a part of CDF? Are some of
> them on board with this vision or do we expect they will join us
> provided this turns out to be the right way to go? My concern is the
> “Continuous Delivery Foundation” feels pretty general and while getting
> under the wings of Linux Foundation is an impressive recognition of what
> we have achieved, it would be unfortunate to make an impression of
> claiming the whole field without wider consensus.
>
> On 16/01/2019 20.01, Marky Jackson wrote:
> > This is very exciting and welcoming!!!
> >
> >> On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi  >> > wrote:
> >>
> >> Ever since our project got our present ‘Jenkins’ name in 2011, we’ve
> >> always been conscious about the governance of this project. It’s a key
> >> part of ensuring the well-being of the project. We’ve not only talked
> >> the talk, but done some walking the walk too, such as team
> >> , JEP
> >> , and SIG .
> >>
> >> One idea in this space that we’ve discussed in and out is software
> >> foundation around Jenkins. Those of you who came to Jenkins World
> >> Contributor Summit in 2017 might remember Tyler presenting this idea
> >> under the name “Jenkins Software Foundation” (see slides
> >> <
> https://docs.google.com/presentation/d/1E3sUlRnfG-Dpmj-Lwrse56S0aUY3PBoGlenU5QwYCXg/edit#slide=id.g16abb2ffe7_0_242>
>
> >> and notes
> >> <
> https://docs.google.com/document/d/1JSxYNI_RuA8ITlxVmxBdFg1A-sOKz-w7a9tzuPfWmr4/edit#heading=h.hc79wlk2cwzn>),
>
> >> at the DevOps World | Jenkins World Contributor Summit in 2018 and
> >> afterwards, Tracy has helped continue this conversation (see slides
> >> <
> https://docs.google.com/presentation/d/1Q-BGZV4H9x0Vo7QsEg-UfT04jQSJ6zuAQXahl9m3iuY/edit?usp=sharing
> >).
> >>
> >> *Why?
> >> *
> >> In a nutshell, the “problems” we are trying to solve here are:
> >>
> >>   * *Limits to current support and services* - Software in the Public
> >> Interest , which currently hosts Jenkins, is
> >> a fairly modest “limited service” non-profit organization. I love
> >> what they do, but we could use more help; entering into legal
> >> contracts, setting up recurring payment that doesn’t go through my
> >> own personal credit card. These inabilities hamper the growth of
> >> the project.
> >>
> >>   * *High barrier to participation by corporate contributors* - Our
> >> unique governance structure makes it unnecessarily hard for
> >> corporate contributors to come in and feel at home. We aren’t an
> >> Apache project, an Eclipse project, nor a company-owned project
> >> like Chef or Spring. We are just a little too unique to be
> >> understood by corporate open-source offices, lawyers, and
> >> pointy-haired bosses. The net result is that we lose out on their
> >> participation and contributions — money and people. I’ve been on
> >> the phone with some of those companies myself, and so has Tracy.
> >>
> >>   * *Misperception that Jenkins is owned by CloudBees* - A common
> >> perception error is that Jenkins is a CloudBees project, when it
> >> really isn’t. But this perception is self-perpetuating. We want a
> >> long-term structure to keep Jenkins alive and thriving, and not
> >> being tied 

Re: [GSOC] Jenkins REST API Client Pipeline Wrapper Plugin Proposal

[Marky Jackson]

This looks good and yes, the step can have multiple methods.

> On Jan 16, 2019, at 6:43 PM, martinda  wrote:
> 
> I am re-working the 3 REST API GSoC proposals...
> 
> How does this example look like in terms of respecting the current execution 
> engine requirements:
> 
> bitbucketClient.withServer(url: “foo://bitbucket”, project: project, repo: 
> repo, crendentialsId: “mybitbucket”) {
> def response = bitbucketClient.pullRequestApi(‘changes’, prNumber)
> echo response.errors // a list
> echo response.errors[0].context // a string
> echo response.errors[0].message // a string
> echo response.changes // a list
> echo response.changes[0].path // a string
> echo response.changes[0].srcPath // a string
> }
> 
> The response object only ever holds simple data types.
> 
> Other question: Is it okay for the step to have multiple methods, but they 
> only return simple data types?
> For example: bitbucketClient.pullRequestApi(prNumber, 'changes'); 
> bitbucketClient.branchApi('list')
> 
> Martin
> 
> 
> -- 
> 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/285c7bae-5e53-4f69-aa6b-28f00186315a%40googlegroups.com
>  
> .
> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/AB1A3360-D69E-4FC1-8913-3B091461ACCA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Jenkins REST API Client Pipeline Wrapper Plugin Proposal

[martinda]

I am re-working the 3 REST API GSoC proposals...

How does this example look like in terms of respecting the current 
execution engine requirements:

bitbucketClient.withServer(url: “foo://bitbucket”, project: project, repo: 
repo, crendentialsId: “mybitbucket”) {
def response = bitbucketClient.pullRequestApi(‘changes’, prNumber)
echo response.errors // a list
echo response.errors[0].context // a string
echo response.errors[0].message // a string
echo response.changes // a list
echo response.changes[0].path // a string
echo response.changes[0].srcPath // a string
}


The response object only ever holds simple data types.

Other question: Is it okay for the step to have multiple methods, but they 
only return simple data types?

For example: bitbucketClient.pullRequestApi(prNumber, 'changes'); 
bitbucketClient.branchApi('list')


Martin


-- 
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/285c7bae-5e53-4f69-aa6b-28f00186315a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new home for Jenkins

[Oliver Gondža]

Those are interesting news. Are we expecting to partner with existing 
communities around existing CD projects as a part of CDF? Are some of 
them on board with this vision or do we expect they will join us 
provided this turns out to be the right way to go? My concern is the 
“Continuous Delivery Foundation” feels pretty general and while getting 
under the wings of Linux Foundation is an impressive recognition of what 
we have achieved, it would be unfortunate to make an impression of 
claiming the whole field without wider consensus.


On 16/01/2019 20.01, Marky Jackson wrote:

This is very exciting and welcoming!!!

On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi > wrote:


Ever since our project got our present ‘Jenkins’ name in 2011, we’ve 
always been conscious about the governance of this project. It’s a key 
part of ensuring the well-being of the project. We’ve not only talked 
the talk, but done some walking the walk too, such as team 
, JEP 
, and SIG .


One idea in this space that we’ve discussed in and out is software 
foundation around Jenkins. Those of you who came to Jenkins World 
Contributor Summit in 2017 might remember Tyler presenting this idea 
under the name “Jenkins Software Foundation” (see slides 
 
and notes 
), 
at the DevOps World | Jenkins World Contributor Summit in 2018 and 
afterwards, Tracy has helped continue this conversation (see slides 
).


*Why?
*
In a nutshell, the “problems” we are trying to solve here are:

  * *Limits to current support and services* - Software in the Public
Interest , which currently hosts Jenkins, is
a fairly modest “limited service” non-profit organization. I love
what they do, but we could use more help; entering into legal
contracts, setting up recurring payment that doesn’t go through my
own personal credit card. These inabilities hamper the growth of
the project.

  * *High barrier to participation by corporate contributors* - Our
unique governance structure makes it unnecessarily hard for
corporate contributors to come in and feel at home. We aren’t an
Apache project, an Eclipse project, nor a company-owned project
like Chef or Spring. We are just a little too unique to be
understood by corporate open-source offices, lawyers, and
pointy-haired bosses. The net result is that we lose out on their
participation and contributions — money and people. I’ve been on
the phone with some of those companies myself, and so has Tracy.

  * *Misperception that Jenkins is owned by CloudBees* - A common
perception error is that Jenkins is a CloudBees project, when it
really isn’t. But this perception is self-perpetuating. We want a
long-term structure to keep Jenkins alive and thriving, and not
being tied to the fate of any single entity is a key requirement.
We want more companies to participate in Jenkins, feel a
co-ownership, and push Jenkins forward together.

  * *Need to coordinated broader community of contributors* - On the
people front, it used to be that the bulk of the forward motion in
this project came from individual plugin developers. Today, where
we need to move forward requires more organized contributors and
skills other than coding. Blue Ocean was a good example. So was
Config as Code, where it took the persistence of two corporate
contributors. Pipeline Authoring SIG
 to me is another
young example where if you look at the key participants, it really
represents organizations and what they are concerned about.

  * *Raising and using money well* - On the money front, we are not
tapping our ability to raise money, and we lack the ability to use
it effectively. On the few

occasions

that we did a donation drive, we have shown incredible ability to
raise money, but I know we can do a few orders of magnitude more.
Plus, this kind of irregular income is difficult to make the most
of, because it’s hard to enter into recurring expenses. Also,
without our own legal entity, we lack the ability to turn the
money into what’s most precious — people!

Given all this, the Jenkins board, CloudBees (as the biggest 
contributor), and the Linux Foundation kept exploring this foundation 
idea beyond those contributor summits. We have floated some 

Re: A new home for Jenkins

[Marky Jackson]

This is very exciting and welcoming!!!

> On Jan 16, 2019, at 10:57 AM, Kohsuke Kawaguchi  wrote:
> 
> Ever since our project got our present ‘Jenkins’ name in 2011, we’ve always 
> been conscious about the governance of this project. It’s a key part of 
> ensuring the well-being of the project. We’ve not only talked the talk, but 
> done some walking the walk too, such as team 
> , JEP 
> , and SIG .
> 
> One idea in this space that we’ve discussed in and out is software foundation 
> around Jenkins. Those of you who came to Jenkins World Contributor Summit in 
> 2017 might remember Tyler presenting this idea under the name “Jenkins 
> Software Foundation” (see slides 
> 
>  and notes 
> ),
>  at the DevOps World | Jenkins World Contributor Summit in 2018 and 
> afterwards, Tracy has helped continue this conversation (see slides 
> ).
> 
> Why?
> 
> In a nutshell, the “problems” we are trying to solve here are:
> 
> Limits to current support and services - Software in the Public Interest 
> , which currently hosts Jenkins, is a fairly modest 
> “limited service” non-profit organization. I love what they do, but we could 
> use more help; entering into legal contracts, setting up recurring payment 
> that doesn’t go through my own personal credit card. These inabilities hamper 
> the growth of the project.
> 
> High barrier to participation by corporate contributors - Our unique 
> governance structure makes it unnecessarily hard for corporate contributors 
> to come in and feel at home. We aren’t an Apache project, an Eclipse project, 
> nor a company-owned project like Chef or Spring. We are just a little too 
> unique to be understood by corporate open-source offices, lawyers, and 
> pointy-haired bosses. The net result is that we lose out on their 
> participation and contributions — money and people. I’ve been on the phone 
> with some of those companies myself, and so has Tracy.
> 
> Misperception that Jenkins is owned by CloudBees - A common perception error 
> is that Jenkins is a CloudBees project, when it really isn’t. But this 
> perception is self-perpetuating. We want a long-term structure to keep 
> Jenkins alive and thriving, and not being tied to the fate of any single 
> entity is a key requirement. We want more companies to participate in 
> Jenkins, feel a co-ownership, and push Jenkins forward together.
> 
> Need to coordinated broader community of contributors - On the people front, 
> it used to be that the bulk of the forward motion in this project came from 
> individual plugin developers. Today, where we need to move forward requires 
> more organized contributors and skills other than coding. Blue Ocean was a 
> good example. So was Config as Code, where it took the persistence of two 
> corporate contributors. Pipeline Authoring SIG 
>  to me is another young example 
> where if you look at the key participants, it really represents organizations 
> and what they are concerned about.
> 
> Raising and using money well - On the money front, we are not tapping our 
> ability to raise money, and we lack the ability to use it effectively. On the 
> few  occasions 
>  that we 
> did a donation drive, we have shown incredible ability to raise money, but I 
> know we can do a few orders of magnitude more. Plus, this kind of irregular 
> income is difficult to make the most of, because it’s hard to enter into 
> recurring expenses. Also, without our own legal entity, we lack the ability 
> to turn the money into what’s most precious — people!
> Given all this, the Jenkins board, CloudBees (as the biggest contributor), 
> and the Linux Foundation kept exploring this foundation idea beyond those 
> contributor summits. We have floated some ideas with some of the companies 
> participating in the ecosystem. Thoughts have evolved, ideas turned into more 
> concrete plans, and I think it has developed to a point where this is 
> beginning to look real, and really makes a lot of sense for the project.
> 
> What?
> 
> So here are the key ideas/features of the foundation:
> 
> We are calling it “Continuous Delivery Foundation” (CDF), and it will have a 
> broader charter. It will house not just Jenkins but other open-source 
> projects in this space. Through the CDF, we want to create open-source 
> solutions collectively addressing the whole software development 

A new home for Jenkins

[Kohsuke Kawaguchi]

Ever since our project got our present ‘Jenkins’ name in 2011, we’ve always
been conscious about the governance of this project. It’s a key part of
ensuring the well-being of the project. We’ve not only talked the talk, but
done some walking the walk too, such as team
, JEP
, and SIG .

One idea in this space that we’ve discussed in and out is software
foundation around Jenkins. Those of you who came to Jenkins World
Contributor Summit in 2017 might remember Tyler presenting this idea under
the name “Jenkins Software Foundation” (see slides

and notes
),
at the DevOps World | Jenkins World Contributor Summit in 2018 and
afterwards, Tracy has helped continue this conversation (see slides

).


*Why?*
In a nutshell, the “problems” we are trying to solve here are:


   - *Limits to current support and services* - Software in the Public
   Interest , which currently hosts Jenkins, is a
   fairly modest “limited service” non-profit organization. I love what they
   do, but we could use more help; entering into legal contracts, setting up
   recurring payment that doesn’t go through my own personal credit card.
   These inabilities hamper the growth of the project.

   - *High barrier to participation by corporate contributors* - Our unique
   governance structure makes it unnecessarily hard for corporate contributors
   to come in and feel at home. We aren’t an Apache project, an Eclipse
   project, nor a company-owned project like Chef or Spring. We are just a
   little too unique to be understood by corporate open-source offices,
   lawyers, and pointy-haired bosses. The net result is that we lose out on
   their participation and contributions — money and people. I’ve been on the
   phone with some of those companies myself, and so has Tracy.

   - *Misperception that Jenkins is owned by CloudBees* - A common
   perception error is that Jenkins is a CloudBees project, when it really
   isn’t. But this perception is self-perpetuating. We want a long-term
   structure to keep Jenkins alive and thriving, and not being tied to the
   fate of any single entity is a key requirement. We want more companies to
   participate in Jenkins, feel a co-ownership, and push Jenkins forward
   together.

   - *Need to coordinated broader community of contributors* - On the
   people front, it used to be that the bulk of the forward motion in this
   project came from individual plugin developers. Today, where we need to
   move forward requires more organized contributors and skills other than
   coding. Blue Ocean was a good example. So was Config as Code, where it took
   the persistence of two corporate contributors. Pipeline Authoring SIG
    to me is another young
   example where if you look at the key participants, it really represents
   organizations and what they are concerned about.

   - *Raising and using money well* - On the money front, we are not
   tapping our ability to raise money, and we lack the ability to use it
   effectively. On the few
    occasions
    that
   we did a donation drive, we have shown incredible ability to raise money,
   but I know we can do a few orders of magnitude more. Plus, this kind of
   irregular income is difficult to make the most of, because it’s hard to
   enter into recurring expenses. Also, without our own legal entity, we lack
   the ability to turn the money into what’s most precious — people!

Given all this, the Jenkins board, CloudBees (as the biggest contributor),
and the Linux Foundation kept exploring this foundation idea beyond those
contributor summits. We have floated some ideas with some of the companies
participating in the ecosystem. Thoughts have evolved, ideas turned into
more concrete plans, and I think it has developed to a point where this is
beginning to look real, and really makes a lot of sense for the project.


*What?*
So here are the key ideas/features of the foundation:


   - We are calling it “Continuous Delivery Foundation” (CDF), and it will
   have a broader charter. It will house not just Jenkins but other
   open-source projects in this space. Through the CDF, we want to create
   open-source solutions collectively addressing the whole software
   development lifecycle, to foster and sustain the ecosystem of open-source,
   vendor-neutral projects through collaborations and interoperability, then
   finally to 

[GSoC 2019] - Status update (we are applying this week!)

[Oleg Nenashev]

Hi all,

Just a quick update of the GSoC sub-project
. GSoC 2019 application period has
started for organization on January 15th and, as you may guess, *we will be
applying *to GSoC this year. Organization profile has been already created

   - We have a sufficient number of project ideas and mentors to apply.
   Actually, we have more project ideas and mentors than in 2016 and 2018 all
   together.
   - We have 20 project ideas
  , 17 of them
  have been already published after initial review rounds, others will be
  published soon
  - We have 23 potential mentors
  - All documentation is in place. We have performed a significant
   rework this year  in order to address retrospective feedback from students
   and mentors
   - We have an application draft under review:
   https://jenkins.io/projects/gsoc/2019/application/ , and we are going to
   submit the first version tomorrow

If Jenkins project is accepted this year, it will be likely the biggest
GSoC we ever had in the project. And we are looking for more mentors,
project ideas and contributors. If you are interested to join the currently
published projects or to propose your own projects
, we encourage
everybody to do that. See the blogpost
 from
Martin for more info.

If you are interested to propose new projects, we recommend it to do it
this month, because potential students have already started reaching out to
the projects and studying the project ideas. We have already got a number
of contributions from potential students. So it is useful to have a project
posted early so that there is more chances to find co-mentors and a great
student for your project.

Best regards,
Oleg Nenashev
Jenkins GSoC org admin

-- 
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/CAPfivLDT6AwOGMk_miZbrXWECx4u%3D3tpyyZPzXQFvcpfCwvfvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.