from:"Kohsuke Kawaguchi"

Up to you --- I just came up with another suggestion, but whatever works
for you is fine by me.

On Tue, Aug 6, 2019 at 9:12 AM Oleg Nenashev  wrote:

> Should we just mark the method as `@Restricted(NoExternalUse.class)` in
> JTH so that all production build fail by default?
> This method is IMO dangerous by default
>
> On Tue, Aug 6, 2019 at 6:04 PM Oleg Nenashev 
> wrote:
>
>> Oleg, how does this test pass for you (and presumably the CI system that
>>> gated this change) with the interactiveBreak invocation intact?
>>>
>>
>> I do not run tests locally when integrating changes, I rely on CI.
>> And CI was green, not sure why.
>>
>> The issue itself came from https://github.com/jenkinsci/jenkins/pull/3802
>> , and it definitely did not get noticed during code reviews.
>>
>>
>>
>>
>>
>> On Tuesday, August 6, 2019 at 5:49:24 PM UTC+2, Kohsuke Kawaguchi wrote:
>>>
>>> I created https://github.com/jenkinsci/jenkins/pull/4142 to get us past
>>> this blockage.
>>>
>>> On Tue, Aug 6, 2019 at 8:42 AM Kohsuke Kawaguchi 
>>> wrote:
>>>
>>>> Thanks Lloyd. With Surefire 2.20.1, the error message changes more
>>>> explicitly to timeout:
>>>> https://gist.github.com/kohsuke/4d31b8dbcbfe1926e71ccba08f7f9555
>>>>
>>>> The test case in question includes an invocation of 'interactiveBreak',
>>>> which is surely wrong? When I remove that line, the test passes.
>>>>
>>>> Oleg, how does this test pass for you (and presumably the CI system
>>>> that gated this change) with the interactiveBreak invocation intact?
>>>>
>>>>
>>>>
>>>> On Tue, Aug 6, 2019 at 12:57 AM Lloyd Chang  wrote:
>>>>
>>>>> clarification: the quoted version number "2.20.1" was Surefire, and
>>>>> not Jenkins.
>>>>>
>>>>> On Tuesday, August 6, 2019 at 12:36:21 AM UTC-7, Lloyd Chang wrote:
>>>>>>
>>>>>> > We have it fixed in 2.20.1.
>>>>>> > https://issues.apache.org/jira/browse/SUREFIRE-1408
>>>>>>
>>>>>> On Monday, August 5, 2019 at 11:54:30 PM UTC-7, Oleg Nenashev wrote:
>>>>>>>
>>>>>>> I was unable to reproduce it locally on Maven 3.6.0 and Windows.
>>>>>>> Would it be possible to provide a crashdump?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Oleg
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, August 6, 2019 at 6:53:57 AM UTC+2, Kohsuke Kawaguchi
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Currently the release of 2.188 is stuck due to a failing
>>>>>>>> jenkins.triggers.TriggerTest. The log is
>>>>>>>> https://gist.github.com/kohsuke/7ba26b2d9f4a2a49d832610d069d0ab4
>>>>>>>>
>>>>>>>> I'll look into this further later, but if anyone has any thoughts
>>>>>>>> on what might be wrong, that'd be greatly appreciated.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kohsuke Kawaguchi
>>>>>>>>
>>>>>>> --
>>>>> 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 jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>> Kohsuke Kawaguchi
>>>>
>>>
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/l2vGNx289vE/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/5bae9334-db08-4753-b893-c8fb8187ccc2%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/5bae9334-db08-4753-b893-c8fb8187ccc2%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/CAPfivLB5R0y3MYOUYHpSzZMsJCOMmUY1XiwtnAWY_b5pHaib0w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLB5R0y3MYOUYHpSzZMsJCOMmUY1XiwtnAWY_b5pHaib0w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4wRpd__yNOTb-VTqPr7b0ZMD0ko242NRDWQoR%3Dgy6Dfrw%40mail.gmail.com.

Re: Jenkins 2.188 release is stuck

I was referring to your attempt to reproduce this earlier this thread.

My guess on why this passes the CI is that it runs in an environment where
stdin is /dev/null, which I suspect will make interactiveBreak() a no-op.
When I run a release or "mvn test" from a terminal, it actually does block.

If my guess is right, it's probably possible to harden interactiveBreak()
to detect that it's reading from /dev/null and fail the test.

On Tue, Aug 6, 2019 at 9:04 AM Oleg Nenashev  wrote:

> Oleg, how does this test pass for you (and presumably the CI system that
>> gated this change) with the interactiveBreak invocation intact?
>>
>
> I do not run tests locally when integrating changes, I rely on CI.
> And CI was green, not sure why.
>
> The issue itself came from https://github.com/jenkinsci/jenkins/pull/3802
> , and it definitely did not get noticed during code reviews.
>
>
>
>
>
> On Tuesday, August 6, 2019 at 5:49:24 PM UTC+2, Kohsuke Kawaguchi wrote:
>>
>> I created https://github.com/jenkinsci/jenkins/pull/4142 to get us past
>> this blockage.
>>
>> On Tue, Aug 6, 2019 at 8:42 AM Kohsuke Kawaguchi 
>> wrote:
>>
>>> Thanks Lloyd. With Surefire 2.20.1, the error message changes more
>>> explicitly to timeout:
>>> https://gist.github.com/kohsuke/4d31b8dbcbfe1926e71ccba08f7f9555
>>>
>>> The test case in question includes an invocation of 'interactiveBreak',
>>> which is surely wrong? When I remove that line, the test passes.
>>>
>>> Oleg, how does this test pass for you (and presumably the CI system that
>>> gated this change) with the interactiveBreak invocation intact?
>>>
>>>
>>>
>>> On Tue, Aug 6, 2019 at 12:57 AM Lloyd Chang  wrote:
>>>
>>>> clarification: the quoted version number "2.20.1" was Surefire, and not
>>>> Jenkins.
>>>>
>>>> On Tuesday, August 6, 2019 at 12:36:21 AM UTC-7, Lloyd Chang wrote:
>>>>>
>>>>> > We have it fixed in 2.20.1.
>>>>> > https://issues.apache.org/jira/browse/SUREFIRE-1408
>>>>>
>>>>> On Monday, August 5, 2019 at 11:54:30 PM UTC-7, Oleg Nenashev wrote:
>>>>>>
>>>>>> I was unable to reproduce it locally on Maven 3.6.0 and Windows.
>>>>>> Would it be possible to provide a crashdump?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Oleg
>>>>>>
>>>>>>
>>>>>> On Tuesday, August 6, 2019 at 6:53:57 AM UTC+2, Kohsuke Kawaguchi
>>>>>> wrote:
>>>>>>>
>>>>>>> Currently the release of 2.188 is stuck due to a failing
>>>>>>> jenkins.triggers.TriggerTest. The log is
>>>>>>> https://gist.github.com/kohsuke/7ba26b2d9f4a2a49d832610d069d0ab4
>>>>>>>
>>>>>>> I'll look into this further later, but if anyone has any thoughts on
>>>>>>> what might be wrong, that'd be greatly appreciated.
>>>>>>>
>>>>>>> --
>>>>>>> Kohsuke Kawaguchi
>>>>>>>
>>>>>> --
>>>> 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 jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>>
>>
>> --
>> Kohsuke Kawaguchi
>>
> --
> 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/5bae9334-db08-4753-b893-c8fb8187ccc2%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/5bae9334-db08-4753-b893-c8fb8187ccc2%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4yFpWt6XsnuYeh1cHqiKVHXV_suT6CeVPrfmM5AzuoFEg%40mail.gmail.com.

Re: Jenkins 2.188 release is stuck

I created https://github.com/jenkinsci/jenkins/pull/4142 to get us past
this blockage.

On Tue, Aug 6, 2019 at 8:42 AM Kohsuke Kawaguchi  wrote:

> Thanks Lloyd. With Surefire 2.20.1, the error message changes more
> explicitly to timeout:
> https://gist.github.com/kohsuke/4d31b8dbcbfe1926e71ccba08f7f9555
>
> The test case in question includes an invocation of 'interactiveBreak',
> which is surely wrong? When I remove that line, the test passes.
>
> Oleg, how does this test pass for you (and presumably the CI system that
> gated this change) with the interactiveBreak invocation intact?
>
>
>
> On Tue, Aug 6, 2019 at 12:57 AM Lloyd Chang  wrote:
>
>> clarification: the quoted version number "2.20.1" was Surefire, and not
>> Jenkins.
>>
>> On Tuesday, August 6, 2019 at 12:36:21 AM UTC-7, Lloyd Chang wrote:
>>>
>>> > We have it fixed in 2.20.1.
>>> > https://issues.apache.org/jira/browse/SUREFIRE-1408
>>>
>>> On Monday, August 5, 2019 at 11:54:30 PM UTC-7, Oleg Nenashev wrote:
>>>>
>>>> I was unable to reproduce it locally on Maven 3.6.0 and Windows.
>>>> Would it be possible to provide a crashdump?
>>>>
>>>> Thanks in advance,
>>>> Oleg
>>>>
>>>>
>>>> On Tuesday, August 6, 2019 at 6:53:57 AM UTC+2, Kohsuke Kawaguchi wrote:
>>>>>
>>>>> Currently the release of 2.188 is stuck due to a failing
>>>>> jenkins.triggers.TriggerTest. The log is
>>>>> https://gist.github.com/kohsuke/7ba26b2d9f4a2a49d832610d069d0ab4
>>>>>
>>>>> I'll look into this further later, but if anyone has any thoughts on
>>>>> what might be wrong, that'd be greatly appreciated.
>>>>>
>>>>> --
>>>>> Kohsuke Kawaguchi
>>>>>
>>>> --
>> 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/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Kohsuke Kawaguchi
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zrE%3DybktmRMf187nd-EtbWnt6x_OqrmoC85sY1%3D-FHaw%40mail.gmail.com.

Re: Jenkins 2.188 release is stuck

Thanks Lloyd. With Surefire 2.20.1, the error message changes more
explicitly to timeout:
https://gist.github.com/kohsuke/4d31b8dbcbfe1926e71ccba08f7f9555

The test case in question includes an invocation of 'interactiveBreak',
which is surely wrong? When I remove that line, the test passes.

Oleg, how does this test pass for you (and presumably the CI system that
gated this change) with the interactiveBreak invocation intact?



On Tue, Aug 6, 2019 at 12:57 AM Lloyd Chang  wrote:

> clarification: the quoted version number "2.20.1" was Surefire, and not
> Jenkins.
>
> On Tuesday, August 6, 2019 at 12:36:21 AM UTC-7, Lloyd Chang wrote:
>>
>> > We have it fixed in 2.20.1.
>> > https://issues.apache.org/jira/browse/SUREFIRE-1408
>>
>> On Monday, August 5, 2019 at 11:54:30 PM UTC-7, Oleg Nenashev wrote:
>>>
>>> I was unable to reproduce it locally on Maven 3.6.0 and Windows.
>>> Would it be possible to provide a crashdump?
>>>
>>> Thanks in advance,
>>> Oleg
>>>
>>>
>>> On Tuesday, August 6, 2019 at 6:53:57 AM UTC+2, Kohsuke Kawaguchi wrote:
>>>>
>>>> Currently the release of 2.188 is stuck due to a failing
>>>> jenkins.triggers.TriggerTest. The log is
>>>> https://gist.github.com/kohsuke/7ba26b2d9f4a2a49d832610d069d0ab4
>>>>
>>>> I'll look into this further later, but if anyone has any thoughts on
>>>> what might be wrong, that'd be greatly appreciated.
>>>>
>>>> --
>>>> Kohsuke Kawaguchi
>>>>
>>> --
> 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/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/1bd559a1-7c52-4a60-91ad-9c2f97ebe8d5%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4xqPDTq3wvo_5s%2B9Qhx%3DUH6-fvJtPVBf7N-RauNDsMpjw%40mail.gmail.com.

Jenkins 2.188 release is stuck

2019-08-05 Thread Kohsuke Kawaguchi

Currently the release of 2.188 is stuck due to a failing
jenkins.triggers.TriggerTest. The log is
https://gist.github.com/kohsuke/7ba26b2d9f4a2a49d832610d069d0ab4

I'll look into this further later, but if anyone has any thoughts on what
might be wrong, that'd be greatly appreciated.

-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4yZGKt8W1Vk8eVZgsSvNLG9N07j24dERj7JX632WP-P-Q%40mail.gmail.com.

[ANN] Active committer representative for the CDF

2019-05-10 Thread Kohsuke Kawaguchi

Hi,

As per the charter of the CDF
<https://github.com/cdfoundation/charter/blob/master/CHARTER.md#3-governing-board>,
there will be an upcoming election to send some of the representatives from
the active committers to the governing board (GB).

The GB meets occasionally (currently every few months) to provide checks
and oversights to what's going on in the foundation. It largely consists of
member companies who contributed money, and it's mainly making sure that
money is spent well. As the name implies, the active committer
representative is to represent the voice of the contributors in that seat.
The term is one year.

The key dates are *May 29*, when nomination closes. The election will be by
contributors. The details of the procedure is determined by the GB.

As the CDF TOC member representing the Jenkins project, I'd like to
nominate some people to this election.

So I talked with Tyler & Tracy a bit and here's what I think we should do:

- If you'd like to nominate somebody (including yourself), please let
the board know at jenkinsci-bo...@googlegroups.com, ideally within the
next week. Please add a brief statement of why.
- The board might reach out to some of you ourselves to encourage you to
nominate yourself.
- The goal is to submit a couple of high quality nominations. So if we
end up getting lots of nominations, we'll pick the best candidates.

To help us find the best niminees, here's what's expected in this role:

- This is a community building role. Somebody who can communicate well,
build a bridge, and advocate for a good cause will thrive.
- You represent contributors and their interests, so somebody who
understands that and is willing to talk to other contributors will thrive.
- This is not a full time work (and there's no compensation, just to be
clear), but you get what you invest in, time wise. So we want people who is
willing to engage and spend time, as opposed to somebody who just sits
there and doesn't do anything.

--
Kohsuke Kawaguchi

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

OpenLab Testing

2019-04-25 Thread Kohsuke Kawaguchi

In my recent trip to Jenkins User Conference China, I met with folks from
Huawei who are behind the OpenLab Testing project
<https://openlabtesting.org/>.

The way I understood it, it's basically a community and free compute
resources for integration testing open-source solutions. I think their
presentation
<https://drive.google.com/open?id=0B5ImblZwZHW4azFSWTY4TUg3TERyZkNDX3NxaXdCTDh3dmFZ>
is
the best quick read material to help you understand where they are headed.

Is this something we can leverage? If there's any interest, I'm happy to
make introductions. They are very open to collaborating with us.

-- 
Kohsuke Kawaguchi

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

Re: DECISION: Jenkins project to join CDF

2019-03-01 Thread Kohsuke Kawaguchi

Thanks! Your +1 like that is helping to people to see that this move is
positive, and that creates an air cover and motivation for people doing the
work.

So I say people can help by bringing more +1s!

On Fri, Mar 1, 2019 at 3:07 PM Marky Jackson 
wrote:

> I am really happy for this. What can we in the community do to help move
> this/make the transition easier?
>
> On Mar 1, 2019, at 2:54 PM, Kohsuke Kawaguchi  wrote:
>
> The two weeks comment period that we set out on Feb 11th has ended. Aside
> from what’s already publicly discussed in the email thread
> <https://groups.google.com/d/topic/jenkinsci-dev/5D8PzawL998/discussion>, the
> last governance meeting
> <http://meetings.jenkins-ci.org/jenkins-meeting/2019/jenkins-meeting.2019-02-27-18.01.html>,
> and past conversations over the year, we didn’t receive any private input
> during this period, positive or negative.
>
> The board has met, and based on all of those, what we see is a fairly
> strong consensus among a small number of people who care about this topic.
> Others seem indifferent, and nobody that we know of are against the move.
>
> So we concluded that we should proceed as the motion proposed in the
> beginning of the public comment period
> <https://groups.google.com/d/msg/jenkinsci-dev/5D8PzawL998/Hhr_ZdG-AAAJ>.
> This is a big thing, so I’m really happy that we got to this point. I want
> to thank everyone for making this happen.
>
> We will begin the process of transferring from SPI, and entering into the
> CDF. In the beginning we are largely going to be working as we have always
> done, and the work mostly entails invisible formality work — recording
> decisions, transferring assets, various paperwork, meetings with those
> foundations, etc. We’ll involve with the relevant team officers, and
> collectively we’ll provide updates. Once the CDF gets going and we are
> there, then more evolutions/changes to the governance should follow, such
> as formalized voting. Such evolution has always been a part of us, and
> those will be individually discussed, like we’ve always done.
>
> As always, any questions, comments, and/or thoughts are welcome.
> --
> Kohsuke Kawaguchi
>
> --
> 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/CAN4CQ4z7wjTUz6URD8ETKmAnvuTBD-d-SM-JKC2AL89wLOrRsw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z7wjTUz6URD8ETKmAnvuTBD-d-SM-JKC2AL89wLOrRsw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> 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/96E50F9B-F395-420D-9F54-60F35DA1B14F%40gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/96E50F9B-F395-420D-9F54-60F35DA1B14F%40gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kohsuke Kawaguchi

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

DECISION: Jenkins project to join CDF

2019-03-01 Thread Kohsuke Kawaguchi

The two weeks comment period that we set out on Feb 11th has ended. Aside
from what’s already publicly discussed in the email thread
<https://groups.google.com/d/topic/jenkinsci-dev/5D8PzawL998/discussion>, the
last governance meeting
<http://meetings.jenkins-ci.org/jenkins-meeting/2019/jenkins-meeting.2019-02-27-18.01.html>,
and past conversations over the year, we didn’t receive any private input
during this period, positive or negative.

The board has met, and based on all of those, what we see is a fairly
strong consensus among a small number of people who care about this topic.
Others seem indifferent, and nobody that we know of are against the move.

So we concluded that we should proceed as the motion proposed in the
beginning of the public comment period
<https://groups.google.com/d/msg/jenkinsci-dev/5D8PzawL998/Hhr_ZdG-AAAJ>.
This is a big thing, so I’m really happy that we got to this point. I want
to thank everyone for making this happen.

We will begin the process of transferring from SPI, and entering into the
CDF. In the beginning we are largely going to be working as we have always
done, and the work mostly entails invisible formality work — recording
decisions, transferring assets, various paperwork, meetings with those
foundations, etc. We’ll involve with the relevant team officers, and
collectively we’ll provide updates. Once the CDF gets going and we are
there, then more evolutions/changes to the governance should follow, such
as formalized voting. Such evolution has always been a part of us, and
those will be individually discussed, like we’ve always done.

As always, any questions, comments, and/or thoughts are welcome.
--
Kohsuke Kawaguchi

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

Re: Request for Input: 2 weeks comment period for moving to the CDF

2019-02-15 Thread Kohsuke Kawaguchi

Ah, code signing keys. Great point.

On Fri, Feb 15, 2019 at 12:28 PM Slide  wrote:

> This sounds great, especially after discussing with Tyler about code
> signing keys and how hard they are to get as an organization under the SPI.
> I think this will be a great thing for Jenkins.
>
> On Thu, Feb 14, 2019 at 7:30 AM R. Tyler Croy  wrote:
>
>> (replies inline)
>>
>> On Mon, 11 Feb 2019, Kohsuke Kawaguchi wrote:
>>
>> > This is the formal call for input for the decision to move the Jenkins
>> > project to the newly forming Continuous Delivery Foundation. (I was told
>> > that my earlier attempt
>> > <https://groups.google.com/d/msg/jenkinsci-dev/1w57jl3K4S4/G1LvRwZEFgAJ>
>> to
>> > just change the subject didn't create a wholly new thread, hence this
>> email)
>>
>>
>> Thanks for splitting this out into a new thread, just to make sure people
>> have
>> the opportunity to see it.
>>
>>
>> I'm personally excited for this move, so if I am unable to attend the
>> meeting
>> next week due to work getting in the way, consider this my emphatic +1 in
>> support of Jenkins moving to the CDF!
>>
>>
>>
>>
>> Cheers
>>
>>
>> --
>> GitHub:  https://github.com/rtyler
>>
>> GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2
>>
>> --
>> 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/20190214143004.GO23906%40grape.brokenco.de
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Website: http://earl-of-code.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/CAPiUgVeOSNsM08yGPr4D_ThcGT0pSS3LvArTdqd1HPoCxNyG9w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVeOSNsM08yGPr4D_ThcGT0pSS3LvArTdqd1HPoCxNyG9w%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kohsuke Kawaguchi

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

Re: Request for Input: 2 weeks comment period for moving to the CDF

2019-02-13 Thread Kohsuke Kawaguchi

Thanks for the question, Rick.

There will be Jenkins level things and CDF level things.

The SIGs that we currently have are Jenkins level entities. In the short
term all of them will remain as is. Over time, I think it makes a lot of
sense that some SIGs be formed at the CDF level --- for example, advocacy
of Continuous Delivery is one project I'd love to see move forward, and it
makes a lot more sense to do that at the CDF level than at the Jenkins
level. When/if CDF-level SIG happens, it's conceivable that some
Jenkins-level SIGs be morphed into CDF-level SIG.

The CDF charter outlines committees that are defined at the CDF level.
More/less might get created over time by the decision of the CDF GB.

The same thing with Ambassador. For the short term Jenkins-level ambassador
will remain, but I think it also makes sense that the ambassadors be
uplifted to the CDF level thing, especially if that makes this program
bigger and better resourced. If after a discussion this is determined to be
the case, then I think that's what's going to happen.

Ultimately, my understanding is that it's really up to people who are
interested in driving things forward to evolve the structure, like how
we've been doing it in this project for the past decade. For the most part,
it's not like those structures are cast in stone by the current charter.
It's a living evolving document that we shape, and what we have right now
is "just" a starting point.

Does that help?

2019年2月12日(火) 17:28 Rick :

> Hi KK,
>
> Thanks for giving more details about the CDF. This is all good from my
> perspective. Just one question I want to ask.
>
> I know the main structure will remain. But how the relationship is going
> between SIG and Committee? Another similar question is about the
> ambassador. The CDF and Jenkins will both have the ambassador or just one
> of them.
>
> Best regards,
> Rick
>
> On Tue, Feb 12, 2019 at 12:35 AM Kohsuke Kawaguchi  wrote:
>
>> This is the formal call for input for the decision to move the Jenkins
>> project to the newly forming Continuous Delivery Foundation. (I was told
>> that my earlier attempt
>> <https://groups.google.com/d/msg/jenkinsci-dev/1w57jl3K4S4/G1LvRwZEFgAJ>
>> to just change the subject didn't create a wholly new thread, hence this
>> email)
>>
>> Speaking as the board, if we are to pull the trigger and formalize this
>> new home, given the magnitude of the proposal, we need to make a binding
>> decision and record it as such. Given that this seems to be a topic that
>> relatively small number of people care about, and that those reactions so
>> far have been overwhelmingly positive, the board would like to set 2 weeks
>> comment period ending on Feb 22nd, where we solicit anyone's organized
>> thoughts on why you think we should or shouldn't move the Jenkins project
>> under the proposed CDF. You can write it here, or if need be, send the
>> board a private email at jenkinsci-bo...@googlegroups.com. We'll
>> consider and respond to them, and provided that there still remains a
>> significant consensus (like the one that we are seeing so far), then the
>> board will make the binding decision.
>>
>> Not much of the existing structure of the Jenkins project will change.
>> Committers, contributors, officers, teams, the board, and all that will
>> still remain (including all the "normalization" work like voting.) The idea
>> is that the board and officers of the Jenkins project will be the
>> "oversight body of each TOC Project" (charter 7-b-i) and this links the
>> chain of authority of the CDF and the Jenkins project. Our existing
>> technical decision making process of JEP, SIG, PR, etc remain under our
>> control. The whole of the draft charter can be seen here
>> <https://drive.google.com/file/d/1QwpyOLRh4o41Hh5GA0FvTB8iNEEW-I9_/view?usp=sharing>.
>> Again, if anyone has questions, concerns, and/or opinions, I'd love to hear
>> those.
>>
>> Please keep the discussion going. Organized thoughts are always better,
>> but if you just want to pile on your +1, that'd be appreciated, too :-)
>>
>> --
>> Kohsuke Kawaguchi
>>
>> --
>> 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/CAN4CQ4z7Q9jXL4PqfqVbBvmjsNy5B6uzEP%2BgnMFu0%2BnGQ6sLXw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4z7Q9jXL4PqfqVbBvmjsNy5B6uzEP%2BgnMFu0%2BnGQ

Request for Input: 2 weeks comment period for moving to the CDF

2019-02-11 Thread Kohsuke Kawaguchi

This is the formal call for input for the decision to move the Jenkins
project to the newly forming Continuous Delivery Foundation. (I was told
that my earlier attempt
<https://groups.google.com/d/msg/jenkinsci-dev/1w57jl3K4S4/G1LvRwZEFgAJ> to
just change the subject didn't create a wholly new thread, hence this email)

Speaking as the board, if we are to pull the trigger and formalize this new
home, given the magnitude of the proposal, we need to make a binding
decision and record it as such. Given that this seems to be a topic that
relatively small number of people care about, and that those reactions so
far have been overwhelmingly positive, the board would like to set 2 weeks
comment period ending on Feb 22nd, where we solicit anyone's organized
thoughts on why you think we should or shouldn't move the Jenkins project
under the proposed CDF. You can write it here, or if need be, send the
board a private email at jenkinsci-bo...@googlegroups.com. We'll consider
and respond to them, and provided that there still remains a significant
consensus (like the one that we are seeing so far), then the board will
make the binding decision.

Not much of the existing structure of the Jenkins project will change.
Committers, contributors, officers, teams, the board, and all that will
still remain (including all the "normalization" work like voting.) The idea
is that the board and officers of the Jenkins project will be the
"oversight body of each TOC Project" (charter 7-b-i) and this links the
chain of authority of the CDF and the Jenkins project. Our existing
technical decision making process of JEP, SIG, PR, etc remain under our
control. The whole of the draft charter can be seen here
<https://drive.google.com/file/d/1QwpyOLRh4o41Hh5GA0FvTB8iNEEW-I9_/view?usp=sharing>.
Again, if anyone has questions, concerns, and/or opinions, I'd love to hear
those.

Please keep the discussion going. Organized thoughts are always better, but
if you just want to pile on your +1, that'd be appreciated, too :-)

--
Kohsuke Kawaguchi

--
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/CAN4CQ4z7Q9jXL4PqfqVbBvmjsNy5B6uzEP%2BgnMFu0%2BnGQ6sLXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

2 weeks comment period (was: Re: A new home for Jenkins)

2019-02-08 Thread Kohsuke Kawaguchi

In FOSDEM, we organized a BOF session in which we talked a bit more about
the CDF among 20-40 people who gathered. The response was good.

Attached is the charter of the CDF
<https://drive.google.com/file/d/1QwpyOLRh4o41Hh5GA0FvTB8iNEEW-I9_/view?usp=sharing>.
This is the terms in which the Jenkins project is considering to move under
the CDF. From the page 7 and onward, there's a bunch of details that
describe the structure of the CDF.

Not much of the existing structure of the Jenkins project will change.
Committers, contributors, officers, teams, the board, and all that will
still remain (including all the "normalization" work like voting.) The idea
is that the board and officers of the Jenkins project will be the
"oversight body of each TOC Project" (charter 7-b-i) and this links the
chain of authority of the CDF and the Jenkins project. Our existing
technical decision making process of JEP, SIG, PR, etc remain under our
control. Again, if anyone has questions, concerns, and/or opinions, I'd
love to hear those.

Now, putting my board hat on, I talked with the other board members (aka
Tyler), and if we are to pull the trigger and formalize this new home,
given the magnitude of the proposal, we need to make a binding decision and
record it as such. Given that this seems to be a topic that relatively
small number of people care about, and that those reactions so far have
been overwhelmingly positive, the board would like to set 2 weeks comment
period ending on Feb 22nd, where we solicit anyone's organized thoughts on
why you think we should or shouldn't move the Jenkins project under the
proposed CDF. You can write it here, or if need be, send the board a
private email at jenkinsci-bo...@googlegroups.com. We'll consider and
respond to them, and provided that there still remains a significant
consensus (like the one that we are seeing so far), then the board will
make the binding decision.

Please keep the conversation going.

2019年1月24日(木) 9:40 Kohsuke Kawaguchi :

> Thanks everyone who came to the Q The slides are available here
> <https://docs.google.com/presentation/d/1HMJptm6-hJVfaOc5sKc2X8z_1_PuTWcx2YZSSdxLmTs/edit?usp=sharing>
> & the recording is available here.
> <https://www.youtube.com/watch?v=Q72coM3gRbM>
>
> If you are coming to FOSDEM, be sure to let us hear your thoughts.
>
> 2019年1月22日(火) 11:29 Liam Newman :
>
>> Hello everyone!
>>
>> We'll be doing an online Q on this tomorrow:
>> January 23rd, 2019 - 10am PST (6pm UTC)
>> Zoom: https://zoom.us/j/165732888
>> Here's a link to the Google calendar event
>> <https://calendar.google.com/event?action=TEMPLATE=NjAxMmliaXRoYnRiYmxrMjJlOW80dW5pa3QgNHNzMTJmMG1xcjN0YnAxdDJmZTM2OXNsZjRAZw=4ss12f0mqr3tbp1t2fe369slf4%40group.calendar.google.com>
>>
>> Please join us and bring any questions you might have.
>>
>>
>>
>>
>> On Thursday, January 17, 2019 at 3:02:09 PM UTC-8, Kohsuke Kawaguchi
>> wrote:
>>>
>>>
>>> On Thu, Jan 17, 2019 at 12:26 AM nicolas de loof 
>>> wrote:
>>>
>>>> That's a great new imho. This is not just about getting Jenkins
>>>> community find a legal status. This is about building a full ecosystem and
>>>> get collaboration with many other tools and vendor in this area. I remember
>>>> the CNCF announcement, which was a tiny thing, and became a fantastic
>>>> ecosystem. I hope CDF will bring the same dynamic.
>>>>
>>>
>>> Right, that's the goal. My hope is that the broad term that is
>>> "Continuous Delivery" creates a big enough umbrella for enough projects and
>>> the communities to work together. Also, these OSS projects working better
>>> together is beneficial for user organizations, and that's how we hope to
>>> drive more participations.
>>>
>>>
>>>
>>>> Le jeu. 17 janv. 2019 à 07:49, Rick  a écrit :
>>>>
>>>>> 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 l

Re: Too many job in ci.jenkins.io

2019-02-08 Thread Kohsuke Kawaguchi

This excessive rebuilding behaviour also causes lots of ops overhead by
eating up disk space.

I think we need to change the current behaviour of ci.jenkins.io.

2019年2月8日(金) 6:25 Jesse Glick :

> On Fri, Feb 8, 2019 at 2:40 AM Baptiste Mathus  wrote:
> > Each merge generally rebuilds all ongoing PRs.
>
> It does not have to be this way.
>
> https://issues.jenkins-ci.org/browse/INFRA-1633
>
> Closing potentially valid, though slow-moving, PRs just to prevent
> Jenkins from endlessly rebuilding them seems perverse when the actual
> problem can be corrected directly.
>
> --
> 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/CANfRfr355LqhOH3rk3n0TnvXk%3D8ykb0vrsXjj_sWdHR3%3Dog7vg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kohsuke Kawaguchi

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

Re: Jenkins WeChat performance for January

2019-02-01 Thread Kohsuke Kawaguchi

This is great!

2019年2月1日(金) 10:20 Rick :

> Hi all,
>
> Here are the January highlights for the Jenkins WeChat accounts:
>
> - Upto 1045  subscribers
> - Total 12 articles
> - Top readers/counts in one day, 190/597
>
> Bring the new contributors:
> @donhui @yuzp1996 @Ddd jack  @P01son6415
>
>
> Regards,
> Rick
>
> --
> https://github.com/LinuxSuRen
>
> --
> 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/CAMM7nTFBLaJEHfXERQ3e7RC5kB_VKhUZm0MbQmiqb0g-0zgMpQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFBLaJEHfXERQ3e7RC5kB_VKhUZm0MbQmiqb0g-0zgMpQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kohsuke Kawaguchi

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

Re: A new home for Jenkins

2019-01-24 Thread Kohsuke Kawaguchi

Thanks everyone who came to the Q The slides are available here
<https://docs.google.com/presentation/d/1HMJptm6-hJVfaOc5sKc2X8z_1_PuTWcx2YZSSdxLmTs/edit?usp=sharing>
& the recording is available here.
<https://www.youtube.com/watch?v=Q72coM3gRbM>

If you are coming to FOSDEM, be sure to let us hear your thoughts.

2019年1月22日(火) 11:29 Liam Newman :

> Hello everyone!
>
> We'll be doing an online Q on this tomorrow:
> January 23rd, 2019 - 10am PST (6pm UTC)
> Zoom: https://zoom.us/j/165732888
> Here's a link to the Google calendar event
> <https://calendar.google.com/event?action=TEMPLATE=NjAxMmliaXRoYnRiYmxrMjJlOW80dW5pa3QgNHNzMTJmMG1xcjN0YnAxdDJmZTM2OXNsZjRAZw=4ss12f0mqr3tbp1t2fe369slf4%40group.calendar.google.com>
>
> Please join us and bring any questions you might have.
>
>
>
>
> On Thursday, January 17, 2019 at 3:02:09 PM UTC-8, Kohsuke Kawaguchi wrote:
>>
>>
>> On Thu, Jan 17, 2019 at 12:26 AM nicolas de loof 
>> wrote:
>>
>>> That's a great new imho. This is not just about getting Jenkins
>>> community find a legal status. This is about building a full ecosystem and
>>> get collaboration with many other tools and vendor in this area. I remember
>>> the CNCF announcement, which was a tiny thing, and became a fantastic
>>> ecosystem. I hope CDF will bring the same dynamic.
>>>
>>
>> Right, that's the goal. My hope is that the broad term that is
>> "Continuous Delivery" creates a big enough umbrella for enough projects and
>> the communities to work together. Also, these OSS projects working better
>> together is beneficial for user organizations, and that's how we hope to
>> drive more participations.
>>
>>
>>
>>> Le jeu. 17 janv. 2019 à 07:49, Rick  a écrit :
>>>
>>>> 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 >>>> >> <mailto:k...@kohsuke.org>> wrot

Re: Infrastructure Maintenance - Tuesday 22th of January at 8PM (UTC)

2019-01-22 Thread Kohsuke Kawaguchi

Thanks for driving this and the heads up.

2019年1月21日(月) 0:45 Olblak :

> Hello,
>
> We'll do an infrastructure maintenance tomorrow Tuesday 22th of January at
> 8PM (UTC) 
>
> The purpose of this maintenance is to upgrade every Ubuntu servers from
> version 14.04 to 18.04 as version 14.04 is getting end of life in April
> 2019.
>
> For each machine, we'll have to do a packages distribution upgrade then
> upgrade puppet agents and finally reboot each machines in order to use the
> latest kernel available.
>
> This maintenance implies downtime and will affect the following services:
>
> * wiki.jenkins.io
> * issues.jenkins.io
> * ci.jenkins.io
> * trusted.ci
> * mirrors.jenkins.io
> * usage.jenkins.io
> * rating.jenkins.io
>
> So please take this into consideration if you have some works that need to
> be done, especially regarding jira and confluence.
>
> If you have any concerns, feel free to tell it.
>
> As usually we'll be available on IRC "#jenkins-infra" channel and during
> the maintenance we'll also be in a hangeout session.
> We'll share a link on IRC.
>
> The related Jira ticket is INFRA-1962
> <https://issues.jenkins-ci.org/browse/INFRA-1962>
>
> Cheers
>
> --
> 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/1548060351.3450323.1639757552.791033E4%40webmail.messagingengine.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/1548060351.3450323.1639757552.791033E4%40webmail.messagingengine.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zP-Bc7EXD-YQ6OshZQDJrejmWZ1O%2Bm_ZGuE5cWYdqtmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A new home for Jenkins

2019-01-17 Thread Kohsuke Kawaguchi

On Thu, Jan 17, 2019 at 12:26 AM nicolas de loof 
wrote:

> That's a great new imho. This is not just about getting Jenkins community
> find a legal status. This is about building a full ecosystem and get
> collaboration with many other tools and vendor in this area. I remember the
> CNCF announcement, which was a tiny thing, and became a fantastic
> ecosystem. I hope CDF will bring the same dynamic.
>

Right, that's the goal. My hope is that the broad term that is "Continuous
Delivery" creates a big enough umbrella for enough projects and the
communities to work together. Also, these OSS projects working better
together is beneficial for user organizations, and that's how we hope to
drive more participations.



> Le jeu. 17 janv. 2019 à 07:49, Rick  a écrit :
>
>> 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 >> >> <mailto:k...@kohsuke.org>> 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
>>> >> <https://wiki.jenkins.io/display/JENKINS/Team+Leads>, JEP
>>> >> <https://github.com/jenkinsci/jep>, and SIG <https://jenkins.io/sigs/
>>> >.
>>> >>
>>> >> 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

Re: A new home for Jenkins

2019-01-17 Thread Kohsuke Kawaguchi

On Wed, Jan 16, 2019 at 10:49 PM Rick  wrote:

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

Yeah, exactly, that's precisely one of the goals.


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

Thank you for all that you've been doing with the Jenkins project. The CDF,
especially as more projects will join, create more platform and message
that we can speak.

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

Yes, as it gets closer to the reality a lot of work will happen through the
Linux Foundation, who runs the CDF.


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 > >> <mailto:k...@kohsuke.org>> 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
>> >> <https://wiki.jenkins.io/display/JENKINS/Team+Leads>, JEP
>> >> <https://github.com/jenkinsci/jep>, and SIG <https://jenkins.io/sigs/
>> >.
>> >>
>> >> 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 <http://spi-inc.org/>, 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 rec

Re: What resources is Cloudbees allocating to Blue Ocean maintenance/development?

2019-01-17 Thread Kohsuke Kawaguchi

 who log into
>> https://gitter.im/jenkinsci/blueocean-plugin seem to be doing so as a
>> best-effort/volunteer level.  For example, on Nov. 16, Keith Zantow
>> reported:
>>
>>
>> *Keith Zantow @kzantow Nov 16 06:36 @rodrigc hard to say exactly what's
>> in the road map at this moment, but certainly open to patches*
>>
>> Can someone in Cloudbees management comment on the company's commitment
>> to Blue Ocean?
>>
>> I try to do what I can.  I've submitted one bugfix:
>> https://github.com/jenkinsci/blueocean-plugin/pull/1794
>>
>> And submitted a few bug reports:
>> https://bit.ly/2B8MmmQ
>>
>> Blue Ocean is very good, but needs some bugfixes and usability
>> fixes to meet parity with the Jenkins Classic UI.
>> Blue Ocean is some complicated "modern JavaScript", and I don't
>> have enough time to dig into it to fix the problems myself.
>>
>> I am trying to push Blue Ocean and Pipeline very heavily at the companies
>> I work for, and for the most part everyone I talk to really likes Blue
>> Ocean,
>> but the bugs/gaps are a problem for wider adoption/success in the projects
>> I work on.
>>
>> Thanks for any feedback.
>>
>> --
>> Craig
>>
>>
>>
> --
> 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/f10ccbbe-41ff-483f-a54d-bdebf2908670%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/f10ccbbe-41ff-483f-a54d-bdebf2908670%40googlegroups.com?utm_medium=email_source=footer>
> .
> 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/5D2BC7B4-E303-4F9D-B127-092A76AF70A5%40gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/5D2BC7B4-E303-4F9D-B127-092A76AF70A5%40gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4w6YTyJ0Mei0EQQWDj0vHQkJ9WHYd1%2B_SfFypvnw1k%2BWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

A new home for Jenkins

2019-01-16 Thread Kohsuke Kawaguchi

through collaborations and interoperability, then
finally to advocate these ideas and encourage collaborations among
practitioners to share and improve their practices.

- The CDF will be a sub-foundation under the Linux Foundation, and it’s
somewhat like CNCF <https://www.cncf.io/>, The Linux Foundation has
experience running lots of sub-foundations in different situations, which
will be a great asset.

- The CDF will have corporate members paying annual dues, which would
create a stable budget hopefully in the range of $100Ks to $1M+, which
translates to infra cost, LF staff that works on the CDF, events and
meetups, travel grants, etc.

- The CDF will have contributors — you — who may or may not come from
corporate members. The technical decision making continues to be based on
meritocracy— autonomy of the plugins, code review process for core, JEP,
and other established implicit and explicit practices around code do not
change just because of the CDF. Also, when your employer joins the CDF as a
member, you will have an easier time participating in Jenkins more actively
because your organization understands what you are doing better.

- The CDF will have several decision-making bodies, such as the
governance board, the technical oversight committee, and the outreach
committee. The governance board is ultimately where the buck stops, and if
you look at the Jenkins governance board today, you can see how it’s
possible that technical decision making is separated from this. The
technical oversight committee is for coordination between projects under
the CDF, design a project lifecycle under the CDF. The outreach committee
is for the noise making — events, marketing, advocacy, that sort of things.

- The CDF will have multiple projects, which are somewhat loosely
connected to the CDF, by connecting the Jenkins governance board under the
TOC in the CDF. What we are suggesting here is that we take Jenkins and
Jenkins X as separate projects under the CDF, as a reflection of the
reality today that these two sibling projects operate differently.

- As an added bonus, the LF has a legal representation in China, and our
recent experience

<https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFvfAKco%3DRxJ6jXCmwX39%2ByexfC1s8TZLwGSZ4dTLberQ%40mail.gmail.com?utm_medium=email_source=footer>
suggests this would be helpful. This is just in time for our growing
Chinese community <https://jenkins.io/sigs/chinese-localization/>.

Also, just to avoid any misunderstanding, this isn’t CloudBees trying to
slowly pull out of Jenkins. As you saw in 2018
<https://jenkins.io/blog/2018/12/25/year-in-review/>, CloudBees went all in
on many new efforts, and this will continue. This is more of an aggressive
growth play. We want more folks to join the project so that we can push it
forward faster. There’s so much to do!!

*Next Steps*
This is really only a high-level overview, but it’s already a lot to chew
on. This plan isn’t cast in stone, this is a multi-party dance to find and
agree on something mutually beneficial, of which the Jenkins project is a
key participant. I know people will need details to get a clearer picture
of what this thing is, and we will provide that soon, but first I’d also
like to encourage people to look at and comment on the big picture, not
just the details — it’s a bit like the difference between commenting on a
JEP vs. commenting on pull requests.

Needless to say, this is a collective decision for us, one that requires a
significant level of consensus. This email is meant to start that
conversation, and I’m looking forward to it.
--
Kohsuke Kawaguchi

--
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/CAN4CQ4z%2BQzaBc1pDtciKXH%3DMhB3vUR%3DCShiFbwy__2W6eEH_EQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What resources is Cloudbees allocating to Blue Ocean maintenance/development?

2019-01-02 Thread Kohsuke Kawaguchi

Thanks for your positive words and the suggestions.

Speaking as myself, not necessarily representing CloudBees' collective
opinion, the idea of one person playing a leadership role is quite
consistent with what we've been generally doing lately in the Jenkins
project -- plugin maintainers, officers, SIG leaders, and JEP sponsors to
name a few. I think its effect of creating an information flow has been
useful. So I'm a big fan of that.


On Wed, Dec 26, 2018 at 9:30 PM Craig Rodrigues  wrote:

> Kohsuke,
>
> Thanks for your honest and open response about my query about Cloudbees
> resources allocated to Blue Ocean.
>
> I am very happy with Cloudbees' investment in Blue Ocean.  When I show the
> UI to co-workers
> and managers, they are impressed.  That in turn makes it easier to promote
> the use of Pipeline
> and other "modern" Jenkins technologies in organizations that are using
> Jenkins, but may not be on the latest stuff.
>
> In terms of Blue Ocean, I have seen initially a very active and engaging
> involvement from Cloudbees in terms
> of kicking off the project and carrying it along.  Unfortunately, the
> involvement from Cloudbees has become much
> more passive.  From what you have described, there are a few passionate
> and talented developers
> at Cloudbees who are holding the fort on Blue Ocean.  I am grateful for
> the enthusiasm, skill, and motivation
> of these developers.  It is always a pleasure to interact with Cloudbees
> developers.
>
> However, my concern is that if the current mode is "holding the fort",
> then the appearance from the
> outside is that Blue Ocean is being passionately supported by a few
> developers, but it is not
> a high priority from Cloudbees management, and the developers are not
> being actively supported or given a clear
> direction/roadmap to work on Blue Ocean.  In other companies, I have seen
> where this mode of operation
> can lead to burnout and frustration on behalf of developers.
>
> I understand that Cloudbees is focusing on a lot of technical areas which
> are very important for the
> future of the Jenkins ecosystem.  I'm glad to see this.  I also understand
> that resources are limited,
> and deciding what resources to allocate to what project can be tricky.
>
> Blue Ocean is a significant piece of technical work, and due to its
> complexity, I think Cloudbees
> should continue to have a leadership role in its ongoing
> maintenance/bugfixes, and evolution.
> There just are not enough developers in the open source Jenkins community
> who
> are versed enough in modern Javascript/NodeJS to make significant
> contributions to Blue Ocean.
>
> I would like to suggest the following:
>
> 1.  Cloudbees should select one person, either a developer or manager to
> "own" Blue Ocean.
> 2.  The owner of Blue Ocean should make regular appearances (maybe once
> week) in the Blue Ocean gitter channel:
> https://gitter.im/jenkinsci/blueocean-plugin
>  to get an idea what problems the community is having with Blue Ocean,
> and also
>  give periodic updates on future plans, roadmap, etc.
> 3.  All bugs in JIRA should be assigned to this owner of Blue Ocean.
> There should be no unassigned Blue Ocean bugs.
> Also, bugs assigned to previous owners, such as James Dumay, should be
> assigned to the active owner.
> 4.  This owner should triage bugs into separate piles: easy to fix, hard
> to fix, won't fix, etc.
> 5.  Cloudbees should assign 1 or 2 developers to officially work on Blue
> Ocean part-time, say 1 to 2 days a week, to
>  work on the Blue Ocean bug backlog.  If other Cloudbees developers
> pitch in and help out, that's awesome, but
>  there should be at least a few developers officially assigned to Blue
> Ocean, and aware of the roadmap.
> 6.  If possible, Cloudbees should assign a UI/UX person for maybe 1 day a
> week to oversee overall changes to Blue Ocean, and make sure
>  that any changes improve UI and usability, and don't become a new
> kitchen sink.
>
> In terms of the work that needs to be done on Blue Ocean, my gut feeling
> is that there are two categories:
>
> 1.  Maintenance/bugfixes and minor filling of "pot holes" to bring Blue
> Ocean to feature parity with the Classic UI.
> 2.  Major interface changes to the Blue Ocean UI.  For example, adding
> customized test reports to Blue Ocean test report viewer:
> https://issues.jenkins-ci.org/browse/JENKINS-50589
>
> If Cloudbees can at least allocate some resources to officially work on
> Category 1 at a low level of activity,
> that would be an improvement over the current situation.
>
> Thanks again for listening to my feedback.
>
> Feel free to contact me off

Re: [Jenkins GSoC] - Budget status update for 2018 + swag delivery expenses discussion

2019-01-02 Thread Kohsuke Kawaguchi

Thanks for the details, Oleg.

As a board, my continued guidance is that the money the project has raised
is doing no good sitting in SPI, so we should look for ways to use it to
make positive impacts. If we find a great way to spend money and empties
the balance, that's kind of great because we have a great reason to go
raise more money from the community.

As long as we are aligned with that goal, for the kind of dollar amount we
are talking about (~500USD), I think you have a large degree of leeway
here.

On Thu, Dec 27, 2018 at 4:03 PM Oleg Nenashev 
wrote:

> Dear all,
>
> Please find the Jenkins GSoC budget status update for 2018. You can find
> my previous report from July 18 here
> <https://groups.google.com/forum/#!topic/jenkinsci-dev/zS1jzYRoF08>.
> Please note that these estimations are rather approximate ones. GSoC does
> not have a separate budget in the Jenkins project until JEP-8
> <https://github.com/jenkinsci/jep/tree/master/jep/8> is accepted.
>
>- Balance on 01.01.2018: *2387.34 USD*
>- Income in 2018: *4200 USD* in September according to GSoC Org
>Payments
><https://developers.google.com/open-source/gsoc/help/org-payments>
>- Expenses in 2018: *~3750 USD*. Number is approximate (currency
>rates, etc.), because we do not know exact numbers until SPI 2018 report is
>published
>- 1902.94 CHF: DevOps World - Jenkins World sponsorship for Pham Vu
>   Tuan:
>   - 951.26 CHF - GSoC Mentor Summit - Oleg Nenashev
>   - 791.26 CAD - GSoC Mentor Summit - Martin d'Anjou:
>   - 254.41 USD - GSoC Mentor Summit - Jeff Pearce: . The report has
>   not been submitted to SPI yet
>   - Estimated GSoC balance on 01.01.2019:
> *2837.34 USD *
>
> So, finally we did not need extra budget as it was approved in July (
> thread <https://groups.google.com/forum/#!topic/jenkinsci-dev/zS1jzYRoF08>).
> Reasons: 1 project was failed and did not get conference travel
> sponsorship. For the third project we still have some money reserved should
> the student decide to go to a Jenkins conference and present his work (up
> to 1000 USD). Even with that, we have more than 1800 USD reserved for the
> next year.
>
> I would like to spend some of that budget on sending swag to GSoC 2018
> participants who have not yet received the swag at DevOps World - Jenkins
> World and other events (~15 recipients). It was originally planned for GSoC
> 2018, but unfortunately it was significantly delayed (my fault). It would
> be also great to print some extra Jenkins GSoC stickers so that we could
> use them for future events.
>
> My plan is to have a detailed budget calculation for swag by Monday so
> that it could be discussed at the governance meeting. My rough estimation
> is that it is going to be around 500USD, including printing and delivery
> costs. I would appreciate feedback about feasibility of such expense. WDYT?
>
> Best regards,
> Oleg Nenashev
> Jenkins GSoC Org Admin
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "jenkinsci-gsoc-all-public" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-gsoc-all-public+unsubscr...@googlegroups.com.
> To post to this group, send email to
> jenkinsci-gsoc-all-pub...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-gsoc-all-public/CAPfivLC7d142-gpk6sk%3DGe1jZxDtY1sD3Afog5ZP%2B%3D_f%2B%3D%2Bswg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-gsoc-all-public/CAPfivLC7d142-gpk6sk%3DGe1jZxDtY1sD3Afog5ZP%2B%3D_f%2B%3D%2Bswg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: ANN: Limited bandwidth in the Jenkins community (Oleg Nenashev)

2018-12-24 Thread Kohsuke Kawaguchi

;-
>
>   Carlos Sanchez (the SIG leader) will be organizing the meetings
>   going forward
>   -
>
>   There is some unfinished External Build Logging work: JEPs, core
>   patches, External Logging API plugin, and External Logging for
>   Elasticsearch plugin. I grant Jesse Glick and Carlos Sanchez a blanket
>   authorization to become JEP co-sponsors, get write/release permissions 
> to
>   the plugins, and transfer these permissions to others if needed
>   -
>
>Jenkinsfile Runner (link
><https://github.com/jenkinsci/jenkinsfile-runner>). I have taken
>ownership of this component in Autumn, and I have plans to continue working
>on JFR. Original creators (Nicolas and Kohsuke) have merge permissions in
>the repository, and they should be able to approve ownership requests if
>needed. This month Evaristo Gutiérrez <https://github.com/varyvol> and 
> Francisco
>Fernández <https://github.com/fcojfernandez> also became
>co-maintainers of this project, and they have already contributed a lot of
>changes there
>-
>
>Development tools. I maintain some development tools, most notably
>Plugin Compatibility Tester and Custom WAR Packager. Raul Arabaolaza
><https://github.com/raul-arabaolaza/> has write permissions in this
>repository and does a lot of the maintenance work there, so I believe these
>components are covered well
>-
>
>Configuration as Code meeting broadcasts - Ewelina will take over
>video recordings of CasC meetings
>-
>
>Jenkins RU Community. All 4 meetups have co-organizers who can drive
>events if needed. Same for the community chats. I will be working to grant
>Twitter access to somebody
>-
>
>Swiss JAM. I will keep driving it, but I have added Wadeck Follonier
><https://github.com/wadeck> (Jenkins Security team) and Cosmin Cojocar
><https://github.com/ccojocar> (Jenkins X contributor) to event
>co-organizers. So they can organize community events if there is an 
> interest
>
>
> If you have reached the end of this list, thanks a lot for your time!
> Please be sure it is *NOT* a farewell letter. I am very excited about
> Jenkins and about recent changes in the project (SIGs, shift towards Cloud
> Native Jenkins and Jenkins as an engine), and I am looking forward to
> continue contributing to the project A LOT next year. The areas of
> contribution are TBD for now.
>
>
> If you have any questions/feedback or see any gaps in the list above,
> please do not hesitate to ask in this thread or in a private message. If
> somebody wants to take particular areas (e.g. adopt a plugin
> <https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin>), please let me
> know as well. I will do my best to help with knowledge transfers and
> initial onboarding.
>
> Merry Christmas and Happy New Year to all of you,
>
> Oleg
>
>
> --
> 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/d2686b42-8943-43ff-b552-d4997c418612%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/d2686b42-8943-43ff-b552-d4997c418612%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zAiEvgYrfRkW3Z1NcR4TAOr1OMtk%2BVODibmG-EKYVghA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What resources is Cloudbees allocating to Blue Ocean maintenance/development?

2018-12-20 Thread Kohsuke Kawaguchi

Hi, Craig,

First of all, thanks for raising this question, and my apologies for taking 
this long to come back to it. You asked an important question about 
CloudBees’ position and thoughts, so we needed to talk among ourselves for 
me to get to this answer. And this isn’t as easy as we want for a big 
distributed company like us. I will start by saying that CloudBees is 100% 
behind Jenkins. And we don’t just talk the talk, we walk the walk. In 2018, 
our people worked on a lot of different areas of Jenkins, ranging from 
Configuration as Code, “cloud native” improvements, security fixes, Jenkins 
X, Evergreen, and the list goes on. So how does that translate to Blue 
Ocean?

Blue Ocean accomplished many things. It created a great excitement, it made 
many Jenkins users’ lives far better, and it paved the way for driving 
other significant projects that transform Jenkins, such as Jenkins X. At 
the same time, I think it hasn’t yet attained the “escape velocity” of 
community collaboration like core did a decade ago. There are multiple 
reasons for that. Partly, it’s because of  the JavaScript SPA skill set 
requirement that are not readily available within the Jenkins community. 
Also, more importantly, it hasn’t attained the sufficient level of 
extensibility, which made it difficult for plugin developers to contribute 
productively. The team took on some serious efforts to tackle this 
challenge, and you can see them on some branches and JEPs, but it’s a truly 
unique problem, and we haven’t cracked that egg yet. So Blue Ocean is kind 
of at a crossroad — It needs to tackle some hard problems before it can 
attain the true parity with the classic UI, but our initial attempt at that 
didn’t pan out.

In the meantime, what’s happening is that we’ve been focusing on other 
major efforts around Jenkins. Many of those I already mentioned above and 
elsewhere , which all 
require significant brain juice and time. And those big ticket items all 
have major impact on UI. For example, with Cloud Native Jenkins as a 
distributed software, how do we need to put together the UI in that world? 
If CasC is very successful, maybe we can let that take the place of the 
system configuration UI. As those efforts were going out first, Blue Ocean 
was left in a reactive mode.

The bottom line is, as it stands right now, CloudBees haven’t yet come to 
“the CloudBees’ plan” on Blue Ocean. Different people, myself included, 
have various thoughts, but they still need to come together to form one 
coherent plan. The key leader in this process is Jenn Briden 
. She is the product manager that is responsible for 
this area. In authoring this response I talked with her, she has thoughts, 
and she is willing to talk to people if anyone have thoughts and opinions. 
She is interested in working with you and she’ll reach out to you, and I 
suggest others with thoughts to send her an email, while we work on how she 
can more proactively engage in the community.

For the time being, CloudBees is doing what it can to fix regressions, 
bugs, and doing the necessary maintenance to retain the same level of 
functionalities as the rest of Jenkins evolves. Many of the people who have 
worked on Blue Ocean are still around, such as  Keith, Nicu, Josh, Ivan, et 
al. And what you saw is  them holding the fort. I will do my part to ensure 
Jenn to get the necessary organizational support to engage in the community 
and form a plan, and to have that communicated well when that happens.  Or 
if somebody else is willing to step up and carry the torch forward, I’d 
love that, too.

And I recognize this problem applies more broadly. As the pace of 
innovation accelerates, it’s good that our thoughts and thinking continue 
to evolve on key efforts to incorporate more thoughts and polish ideas, but 
it needs to come hand in hand with better communication and engagement, and 
we fell short on the area, as this thread highlights. We had some 
leadership changes, including James’ departure, and that didn’t help 
either.  That’s something I’m well aware of, and me and others having been 
working on it.

That’s the honest answer I can provide at the moment, as CTO of CloudBees. 

On Wednesday, December 12, 2018 at 12:30:10 PM UTC-8, Craig Rodrigues wrote:
>
> Hi,
>
> When BlueOcean was originally being developed, James Dumay,
> who was a Director, Product Management at Cloudbees
> was very active in leading Blue Ocean, and communicating status and
> milestones with the Jenkins community.
>
> Since James has left Cloudbees, what I have observed is:
>
> 1.  No one at the manager/director level is visible on the 
> https://gitter.im/jenkinsci/blueocean-plugin Gitter channel to 
> communicate with users or get feedback
> 2.  Many bugs filed against Blue Ocean in JIRA are unassigned
> 3.  Cloudbees employees who log into 
> https://gitter.im/jenkinsci/blueocean-plugin seem to be doing so as a 
>

Re: Trademark sublicense request: Jenkins WeChat Account in China

2018-11-09 Thread Kohsuke Kawaguchi

The change was merged, so the content is accessible from
http://jenkins.io/wechat.pdf

On Fri, Nov 9, 2018 at 7:01 AM Kohsuke Kawaguchi  wrote:

> Signed letter attached.
>
> I've also asked this be added under jenkins.io here,
> https://github.com/jenkins-infra/jenkins.io/pull/1878 in the hope that
> this helps reinforce the chain of trust.
>
>
> On Fri, Nov 9, 2018 at 3:41 AM arch  wrote:
>
>> Hi, KK, Olivier
>>
>> I'll make a presentation about Jenkins X in KubeCon CloudNativeCon China.
>> I wish I could introduce Jenkins WeChat to other people. So if you are free
>> to help me register Jenkins WeChat subscription account. Here is the
>> register link https://mp.weixin.qq.com/?lang=en_US.
>>
>> Thanks
>> Rick (Zhao Xiaojie)
>>
>>
>> On Thu, Nov 8, 2018 at 10:37 AM arch  wrote:
>>
>>> I agree with the ideas to use wechat-ad...@list.jenkins-ci.org. Please
>>> let me in once you created it. And I think the letter is very important to
>>> me and Jenkins Chinese Community. This could let our people know that the
>>> Jenkins Community think the WeChat subscription account is valuable and
>>> important.
>>>
>>> About your suggestion. I'm ok with that. I believe that we all want to
>>> build a great Jenkins Chinese Community. It's no matter who will create the
>>> account.
>>>
>>> In addition, I have another request. I wonder if you (KK, Olivier, Oleg)
>>> could write a welcome or introduce text about the WeChat account. First,
>>> it's good to let Chinese Jenkins fans know you. Second, I think it's good
>>> for getting more focus from my people.
>>>
>>> Good wish.
>>> Rick (Zhao Xiaojie)
>>>
>>> On Thu, Nov 8, 2018 at 3:17 AM Kohsuke Kawaguchi  wrote:
>>>
>>>> This is just a thought, but alternatively, if it's easier, we can ask
>>>> Olivier (or I) to create a WeChat subscription account, deal with whatever
>>>> authorization process it needs, and add your personal WeChat account as the
>>>> operator of the Jenkins subscription account.
>>>>
>>>> That might reduce the roundtrips?
>>>>
>>>> On Wed, Nov 7, 2018 at 11:13 AM Kohsuke Kawaguchi 
>>>> wrote:
>>>>
>>>>> So in the meeting today we reaffirmed that this isn't the case for
>>>>> trademark sublicensing. I took the action to write a signed letter, as per
>>>>> your request, explaining that you are acting on behalf of the rightful
>>>>> owner of the trademark.
>>>>>
>>>>> I wrote a letter, but the printer at the office is acting out so I
>>>>> can't provide you a signed PDF right now. I'll do that once I get back 
>>>>> home
>>>>> later today.
>>>>>
>>>>> Thanks Rick for clarifying that once created, the subscription account
>>>>> can be operated by multiple personal accounts. It does help with the bus
>>>>> factor <https://en.wikipedia.org/wiki/Bus_factor> problem, we don't
>>>>> have to deal with a shared secret this way.
>>>>>
>>>>> But I still agree with Olivier, in that I think it's important that
>>>>> the email address tied to the community be used to create an account:
>>>>> wechat-ad...@list.jenkins-ci.org. This isn't meant to exclude you
>>>>> from anything, slow you down, or distrust, but as I understand it, it's a
>>>>> part of the hygiene to ensure the chain of control is connected all the 
>>>>> way
>>>>> up to SPI.
>>>>>
>>>>> On Tue, Nov 6, 2018 at 7:26 PM arch  wrote:
>>>>>
>>>>>> The service account must control by an organization or a company. So
>>>>>> I'm going to register the subscription account.
>>>>>>
>>>>>> OK, allow me to introduce more details about the WeChat. There are 5
>>>>>> people could running the subscription account by a long term. And there 
>>>>>> are
>>>>>> 20 people could running the account by a short-term (one month). So don't
>>>>>> be worry about one person could block.
>>>>>>
>>>>>> Another situation is that everyone just could have one WeChat
>>>>>> account(personal account). He must bind his bank card, phone number. And
>>>>>> I'll be the initial person to running this. We will create a process to
>>>

Re: Trademark sublicense request: Jenkins WeChat Account in China

2018-11-07 Thread Kohsuke Kawaguchi

This is just a thought, but alternatively, if it's easier, we can ask
Olivier (or I) to create a WeChat subscription account, deal with whatever
authorization process it needs, and add your personal WeChat account as the
operator of the Jenkins subscription account.

That might reduce the roundtrips?

On Wed, Nov 7, 2018 at 11:13 AM Kohsuke Kawaguchi  wrote:

> So in the meeting today we reaffirmed that this isn't the case for
> trademark sublicensing. I took the action to write a signed letter, as per
> your request, explaining that you are acting on behalf of the rightful
> owner of the trademark.
>
> I wrote a letter, but the printer at the office is acting out so I can't
> provide you a signed PDF right now. I'll do that once I get back home later
> today.
>
> Thanks Rick for clarifying that once created, the subscription account can
> be operated by multiple personal accounts. It does help with the bus
> factor <https://en.wikipedia.org/wiki/Bus_factor> problem, we don't have
> to deal with a shared secret this way.
>
> But I still agree with Olivier, in that I think it's important that the
> email address tied to the community be used to create an account: wechat
> -ad...@list.jenkins-ci.org. This isn't meant to exclude you from
> anything, slow you down, or distrust, but as I understand it, it's a part
> of the hygiene to ensure the chain of control is connected all the way up
> to SPI.
>
> On Tue, Nov 6, 2018 at 7:26 PM arch  wrote:
>
>> The service account must control by an organization or a company. So I'm
>> going to register the subscription account.
>>
>> OK, allow me to introduce more details about the WeChat. There are 5
>> people could running the subscription account by a long term. And there are
>> 20 people could running the account by a short-term (one month). So don't
>> be worry about one person could block.
>>
>> Another situation is that everyone just could have one WeChat
>> account(personal account). He must bind his bank card, phone number. And
>> I'll be the initial person to running this. We will create a process to
>> share this platform.
>>
>> Yes, my idea is that create a repository in jenkins-infra. Put all
>> articles on that. Every contributor could create a PR to publish the
>> article. And the good news is that WeChat supports web api. Finally, we
>> will develop a program to publish these articles.
>>
>>
>>> --
>>> 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/1541533813.954363.1567849448.586ABBE0%40webmail.messagingengine.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/1541533813.954363.1567849448.586ABBE0%40webmail.messagingengine.com?utm_medium=email_source=footer>
>>> .
>>> 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/CAMM7nTFfAF%3Ds8USwNSB-ncU4rCE98eNh%3D6sCZNH9MNeZcFjgCg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFfAF%3Ds8USwNSB-ncU4rCE98eNh%3D6sCZNH9MNeZcFjgCg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Kohsuke Kawaguchi
>
-- 
Kohsuke Kawaguchi

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

Re: Trademark sublicense request: Jenkins WeChat Account in China

2018-11-07 Thread Kohsuke Kawaguchi

So in the meeting today we reaffirmed that this isn't the case for
trademark sublicensing. I took the action to write a signed letter, as per
your request, explaining that you are acting on behalf of the rightful
owner of the trademark.

I wrote a letter, but the printer at the office is acting out so I can't
provide you a signed PDF right now. I'll do that once I get back home later
today.

Thanks Rick for clarifying that once created, the subscription account can
be operated by multiple personal accounts. It does help with the bus factor
<https://en.wikipedia.org/wiki/Bus_factor> problem, we don't have to deal
with a shared secret this way.

But I still agree with Olivier, in that I think it's important that the
email address tied to the community be used to create an account: wechat
-ad...@list.jenkins-ci.org. This isn't meant to exclude you from anything,
slow you down, or distrust, but as I understand it, it's a part of the
hygiene to ensure the chain of control is connected all the way up to SPI.

On Tue, Nov 6, 2018 at 7:26 PM arch  wrote:

> The service account must control by an organization or a company. So I'm
> going to register the subscription account.
>
> OK, allow me to introduce more details about the WeChat. There are 5
> people could running the subscription account by a long term. And there are
> 20 people could running the account by a short-term (one month). So don't
> be worry about one person could block.
>
> Another situation is that everyone just could have one WeChat
> account(personal account). He must bind his bank card, phone number. And
> I'll be the initial person to running this. We will create a process to
> share this platform.
>
> Yes, my idea is that create a repository in jenkins-infra. Put all
> articles on that. Every contributor could create a PR to publish the
> article. And the good news is that WeChat supports web api. Finally, we
> will develop a program to publish these articles.
>
>
>> --
>> 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/1541533813.954363.1567849448.586ABBE0%40webmail.messagingengine.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/1541533813.954363.1567849448.586ABBE0%40webmail.messagingengine.com?utm_medium=email_source=footer>
>> .
>> 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/CAMM7nTFfAF%3Ds8USwNSB-ncU4rCE98eNh%3D6sCZNH9MNeZcFjgCg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFfAF%3Ds8USwNSB-ncU4rCE98eNh%3D6sCZNH9MNeZcFjgCg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: Trademark sublicense request: Jenkins WeChat Account in China

2018-11-01 Thread Kohsuke Kawaguchi

I'm really excited with the prospect of Jenkins project getting WeChat
presence. I've been to China a few times myself, I have my own WeChat
account, and I know how big and ubiquitous this is over there.

That said, where I disagree with Oleg in the email thread linked is that I
don't think it's right that Alauda is tied to this account, or any other
participant for that matter. The idea of this WeChat account is for it to
be the "official" Jenkins account on WeChat. Trademark sublicensing request
is to allow the requester to use the name in question for their purposes
outside official community activity.

>From the community's perspective, where this manifests as a question is how
to share the access to this account with others. For example, what if
Alauda moves on and stops engaging the Jenkins community? What if it gets
acquired? I'm not assuming any malice or meaning to distrust anybody here,
but it's a part of the basic safe guards for shared community assets. This
asset is to be controlled by the community, not by Alauda --- I think
everyone agrees on that here, but let's be very clear about that!

I think the right thing to do is to setup an account that does not require
any company, Alauda or not, to proxy this. Then provided that this is
reasonably easily possible, this account should be tied and owned by the
email address of some community team, say infra team or Chinese
Localization SIG. Then when it comes to the actual operation of this, I
think it's great that Xiaojie is stepping up to the plate. All the powers
to him!!  IIUC, that's "subscription account" and not "service account."

None of this should involve trademark sublicensing, because this IS the
official community effort whose authority is chained to the existing
governance structure.

On Thu, Nov 1, 2018 at 12:22 AM arch  wrote:

> On behalf on Alauda, I'd like to request the permission to use
> the following name that uses 'Jenkins' in it: "Jenkins WeChat Account".
>
> WeChat is a very popular app in China. Most of the people have a WeChat
> account in here. So I thought it's a great place to help grow the Jenkins
> Community. We will post some events like JAM on it. And some articles
> (original or translated from jenkins.io) is helpful for many Jenkins
> users.
>
> You can find out more about discussing details in here:
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTGjLOg7m1uzXHxZaxTd4QFiRXjknBNOsegQ4JjTkkyH2g%40mail.gmail.com?utm_medium=email_source=footer
>
> Thank you.
> Best!
>
> Rick (Zhao Xiaojie)
>
> --
> 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/CAMM7nTFvfAKco%3DRxJ6jXCmwX39%2ByexfC1s8TZLwGSZ4dTLberQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTFvfAKco%3DRxJ6jXCmwX39%2ByexfC1s8TZLwGSZ4dTLberQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Trademark sublicense request: TechMatrix Jenkins Platform Package

2018-10-03 Thread Kohsuke Kawaguchi

On behalf of TechMatrix, Inc. I’d like to request the permission to use the
following name that uses ‘Jenkins’ in it:

   - TechMatrix Jenkins Platform Package

I have relationship with the people in TechMatrix who's doing this through
the community (they are the key people behind Jenkins User Conference in
Tokyo) and CloudBees (they are our partner in Japan.) Their time zone is
not conducive to direct participation in the meeting, so I'm doing this on
behalf of them. They have also requested "Jenkins Day Japan" event name in
the past that got subsequently approved.


To help people understand how this name is going to be used, let me
describe a bit about the effort for which we’d like to use this name.

TechMatrix Jenkins Platform Package (TJPP) is a package of Jenkins, code
analysis tools, testing tools and so on, integrated to work well together.
TechMatrix is offering this commercial solution to companies who can't /
don't want to assemble those pieces themselves, it's a way of helping
customers get more out of pieces that TechMatrix individually sells.

TJPP is meant as an aggregated umbrella brand name for these integrated
solutions, under which different solutions for different audience/context
will come in as "TechMatrix Jenkins Platform Package for $SOMETHING". The
first solution is "TechMatrix Jenkins Platform Package for Java", which
combines CI with Jenkins and Parasoft JTest (static analysis, unit testing
tools), further extensible to test, deployment, releases and so on. The
possible future expansions include "for C/C++", "for C#", and so on.

Technically, I'm not sure if the approval for TJPP implicitly cover "TJPP
for $SOMETHING" or not, but it seems pretty clear to me that if we are OK
with TJPP, we have no reasons to object to any "TJPP for $SOMETHING", so in
order to skip the unnecessary work for everyone, I'd like us to be able to
give them a blanket sublicensing approval for "TJPP for $SOMETHING"

I'll put this in the next week's project meeting agenda, but given that I'm
only proxying this, if you have concerns and questions, please raise it
here beforehand so that they can respond in time.
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4xWkyd7cOtBccqpqCL_22fhGm63A9OeW%2B5f-bH-72z5Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins: Shifting Gears

2018-09-05 Thread Kohsuke Kawaguchi

On Wed, Sep 5, 2018 at 2:45 PM Baptiste Mathus  wrote:

> Side tracking a bit, sorry, beat with me. Not sure for others, but
>
> >  suggest we don't turn this into a mega thread of everything that no one
> can keep track of
>
> Might also have not had the expected effect.
>
> I think mega-threads, though sometimes hard indeed to follow, also show
> the level of interest from people. So maybe like a brainstorming session,
> we shouldn't try and organize it beforehand but actually encourage answers,
> even those that might sound off topic. Then we see what still 'sticks to
> the wall'.
>

I see, yeah, I did write that. Point taken.


Le mer. 5 sept. 2018 à 20:39, Kohsuke Kawaguchi  a écrit :
>
>> Hi, I just wanted to see what people thought of this? It created quite a
>> reaction in places like Hacker News, but I'm not seeing any reaction in
>> here, which is where I care the most.
>>
>> Have people had a chance to read/see it? I'm sure you will have opinions.
>> Please let me know.
>>
>>
>> On Fri, Aug 31, 2018 at 1:33 PM Kohsuke Kawaguchi  wrote:
>>
>>> I've just posted a message to the fellow Jenkins contributors on
>>> jenkins.io: https://jenkins.io/blog/2018/08/31/shifting-gears/
>>>
>>> Any thoughts, feedbacks, etc are appreciated.
>>>
>>> Note that the pitch is at a pretty high level, and much of the things
>>> need to be designed, discussed, implemented, and so on. Those discussions
>>> will happen over coming days and months in here, SIGs, and JEPs, so I
>>> suggest we don't turn this into a mega thread of everything that no one can
>>> keep track of, like what happened with the email thread at the time of
>>> Jenkins 2.
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
>> Kohsuke Kawaguchi
>>
> --
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zFX0EPK7oNH-F162m_fSu5zNY39U0%2BGG9_vqoAFZhwbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins: Shifting Gears

2018-09-05 Thread Kohsuke Kawaguchi

On Wed, Sep 5, 2018 at 12:03 PM Keith Zantow  wrote:

> Hi Kohsuke,
>
> To be honest, theres's a lot to digest. *I encourage everyone to read the
> details rather than skim the headlines* as the entirety of what you're
> talking about is meat rather than fluff.
>
> I think there are a couple bits that are somewhat vague or misunderstood.
> The relationship between Jenkins, Jenkins X, Cloud Native Jenkins, Jenkins
> Jolt, etc. is probably one of the most confusing or misunderstood parts of
> the ecosystem to people who are not particularly familiar with the
> projects. On the surface, it could appear that some of these are
> contradictory or completely different things. Perhaps there could be some
> name mangling of the projects that make things a bit more clear where they
> fall in the ecosystem, along with a plan to align the parts that make sense
> would be welcomed.
>

OK, I hear a similar sentiment from a few more people, I think I can
provide some pictures to help.


>
> Cheers,
> -Keith
>
> On Wed, Sep 5, 2018 at 2:39 PM Kohsuke Kawaguchi  wrote:
>
>> Hi, I just wanted to see what people thought of this? It created quite a
>> reaction in places like Hacker News, but I'm not seeing any reaction in
>> here, which is where I care the most.
>>
>> Have people had a chance to read/see it? I'm sure you will have opinions.
>> Please let me know.
>>
>>
>> On Fri, Aug 31, 2018 at 1:33 PM Kohsuke Kawaguchi  wrote:
>>
>>> I've just posted a message to the fellow Jenkins contributors on
>>> jenkins.io: https://jenkins.io/blog/2018/08/31/shifting-gears/
>>>
>>> Any thoughts, feedbacks, etc are appreciated.
>>>
>>> Note that the pitch is at a pretty high level, and much of the things
>>> need to be designed, discussed, implemented, and so on. Those discussions
>>> will happen over coming days and months in here, SIGs, and JEPs, so I
>>> suggest we don't turn this into a mega thread of everything that no one can
>>> keep track of, like what happened with the email thread at the time of
>>> Jenkins 2.
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
>> Kohsuke Kawaguchi
>>
>> --
>> 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/CAN4CQ4zX%3DDZAS8BD-b40mFruVUPH7zE7cUF-6pWOZQRKr8BGsw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zX%3DDZAS8BD-b40mFruVUPH7zE7cUF-6pWOZQRKr8BGsw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Keith Zantow
> Senior Software Engineer
> CloudBees, Inc.
>
> [image: CloudBees-Logo.png]
>
>
> E: kzan...@cloudbees.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/CAJTHQaFGyPCLzSxrpzOj5qVcVMteNDb8cU_8Ymc%3DiLwVTdvdhg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAJTHQaFGyPCLzSxrpzOj5qVcVMteNDb8cU_8Ymc%3DiLwVTdvdhg%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: Jenkins: Shifting Gears

2018-09-05 Thread Kohsuke Kawaguchi

Hi, I just wanted to see what people thought of this? It created quite a
reaction in places like Hacker News, but I'm not seeing any reaction in
here, which is where I care the most.

Have people had a chance to read/see it? I'm sure you will have opinions.
Please let me know.


On Fri, Aug 31, 2018 at 1:33 PM Kohsuke Kawaguchi  wrote:

> I've just posted a message to the fellow Jenkins contributors on
> jenkins.io: https://jenkins.io/blog/2018/08/31/shifting-gears/
>
> Any thoughts, feedbacks, etc are appreciated.
>
> Note that the pitch is at a pretty high level, and much of the things need
> to be designed, discussed, implemented, and so on. Those discussions will
> happen over coming days and months in here, SIGs, and JEPs, so I suggest we
> don't turn this into a mega thread of everything that no one can keep track
> of, like what happened with the email thread at the time of Jenkins 2.
> --
> Kohsuke Kawaguchi
>
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zX%3DDZAS8BD-b40mFruVUPH7zE7cUF-6pWOZQRKr8BGsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins: Shifting Gears

2018-08-31 Thread Kohsuke Kawaguchi

I've just posted a message to the fellow Jenkins contributors on jenkins.io
: https://jenkins.io/blog/2018/08/31/shifting-gears/

Any thoughts, feedbacks, etc are appreciated.

Note that the pitch is at a pretty high level, and much of the things need
to be designed, discussed, implemented, and so on. Those discussions will
happen over coming days and months in here, SIGs, and JEPs, so I suggest we
don't turn this into a mega thread of everything that no one can keep track
of, like what happened with the email thread at the time of Jenkins 2.
-- 
Kohsuke Kawaguchi

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

Re: ANN: Welcome Google Summer of Code 2018 students!

2018-04-26 Thread Kohsuke Kawaguchi

Woohoo! Welcome!!

I love that you guys are from all over the world. In the past years, I had
the pleasure of mentioning some of the GSoC projects in Jenkins World
keynotes, and other projects have made it to the exhibit hall floor. I'm
looking forward to productive GSoC this year, and I know you guys will go
beyond the bar that's already pretty high!

And last but not least, hat tip to Oleg for his tireless passion to drive
GSoC effort forward.

On Wed, Apr 25, 2018 at 7:14 AM Oleg Nenashev <o.v.nenas...@gmail.com>
wrote:

> Dear all,
>
> On behalf of the Jenkins GSoC team and mentors, I would like to welcome Shenyu
> Zheng <https://github.com/cizezsy>, Udara De Silva
> <https://github.com/udara28>, Pham Vu Tuan <https://github.com/pvtuan10>
> and Abhishek Gautam <https://github.com/gautamabhishek46>. They will be
> working on Google Summer of Code projects in the Jenkins organization, and
> they have already done some contributions.
>
> If you are interested to know more about GSoC in Jenkins, you can find
> information about the project, timeline and communication channels here
> <https://jenkins.io/projects/gsoc/>. This year we will have the following
> projects:
>
>- Code Coverage API Plugin
><https://jenkins.io/projects/gsoc/2018/code-coverage-api-plugin> -
>create a new API Plugin to unify existing Code Coverage plugins in Jenkins
>and provide some new features.
>- Electronic Design Automation Plugins
><https://jenkins.io/projects/gsoc/2018/eda-plugins/> - set of plugins
>for open-source Electronic Design Automation tools for synthesis,
>simulation and coverage analysis (iVerilog, covered, Yosys)
>- Jenkins Remoting over Message Bus/Queue
><https://jenkins.io/projects/gsoc/2018/remoting-over-message-bus/>-
>add support of a popular message queue/bus technology (RabbitMQ or Kafka)
>as a fault-tolerant communication layer in Jenkins
>- Simple Pull-Request Job Plugin
><https://jenkins.io/projects/gsoc/2018/simple-pull-request-job-plugin>
>- add ability to define Jenkins jobs as YAML files stored in SCM
>(configuration-as-code), integrate it with existing plugin ecosystem
>
> During next 4 weeks project teams will be reaching out to potential
> stakeholders in order to establish connections and to get comments
> regarding their project designs. Project designs may change a lot during
> this Community Bonding phase. If you have any comments/proposals/concerns,
> please join the project-specific discussions in the mailing lists once they
> start. We will appreciate any feedback and help with onboarding.
>
>
> Welcome aboard, guys!
>
> Best regards,
> Oleg Nenashev
> Jenkins GSoC Org Team
>
> --
> 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/CAPfivLDwk5VD3jRvUw-irP%2B8JWnzwk9JKJHGZ3BrqD-kPu3fkw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDwk5VD3jRvUw-irP%2B8JWnzwk9JKJHGZ3BrqD-kPu3fkw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: External Artifact Storage

2018-04-20 Thread Kohsuke Kawaguchi

hings in released versions of code is
> IMHO a
> very good thing.
>
>
>
> Cheers
>
>
>
> [0] https://github.com/jenkinsci/jep/tree/master/jep/1#accepted
> [1] https://github.com/jenkinsci/jep/tree/master/jep/1#finalizing-a-jep
>
> --
> 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/20180420163747.GF1836%40grape.lasagna.io
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: POTD: Jenkinsfile Runner

2018-04-04 Thread Kohsuke Kawaguchi

Ouch, that's a shame. It looked like an interesting project, I hope my
writing to you didn't trigger that.

You say "stress builds and also to burn in our build agents" -- can you
elaborate on that? It sounds like you are trying to warm up a cache or
something, but I'm not sure what that means in the context of builds.

On Wed, Apr 4, 2018 at 11:15 AM Tom Shaw <thomas.sha...@gmail.com> wrote:

> Hi Kohsuke,
>
> Thanks for getting in touch. I've had to remove that repo temporarily at
> the request of my former employer. It looks like we are trying to solve the
> same problem. I wanted to use jenkinless to stress builds and also to burn
> in our build agents. It's more of a convenience tool. Running the slave
> using docker in docker worked really well. I might try and turn this into
> an executable that can be stored in the repo alongside code.
>
> Tom
>
>
> On Wed, 4 Apr 2018, 00:19 Kohsuke Kawaguchi, <k...@kohsuke.org> wrote:
>
>> Hi, Thomas,
>>
>> Tyler passed me a link to your project
>> https://github.com/tomwillfixit/jenkinless, which is in a similar space
>> with my project of the day called Jenkinsfile Runner.
>>
>> I haven't studied your project carefully yet, but I already see some
>> interesting ingredients like memcached that I have no idea what you use it
>> for :-)   I'd love to hear from you the philosophy & use cases that led to
>> it. And I'd also love to hear what you think of Jenkinsfile Runner. I think
>> we have similar interests here, are there any opportunity to collaborate?
>>
>> On Thu, Mar 1, 2018 at 11:23 AM Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>>
>>> And of course I forgot to have the link to the project!
>>> https://github.com/kohsuke/jenkinsfile-runner
>>>
>>>
>>> On Thu, Mar 1, 2018 at 11:22 AM Kohsuke Kawaguchi <k...@kohsuke.org>
>>> wrote:
>>>
>>>> Jenkinsfile Runner is an experiment to package Jenkins pipeline
>>>> execution as a command line tool. The intend use cases include:
>>>>
>>>>- Use Jenkins in Function-as-a-Service context
>>>>- Assist editing Jenkinsfile locally
>>>>- Integration test shared libraries
>>>>
>>>> Over the past year, I've done some deep-dive 1:1 conversations with
>>>> some Jenkins users and I felt something like this might move the needle for
>>>> them in an important way.
>>>>
>>>> I'd love to hear any reactions on your side. Could something like this
>>>> be important for you, does it miss any key points for you? If you mentally
>>>> picture a perfect version of this, what would that do, and how would you
>>>> use?
>>>>
>>>> Let me know!
>>>>
>>>> --
>>>> Kohsuke Kawaguchi
>>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
>> Kohsuke Kawaguchi
>>
> --
Kohsuke Kawaguchi

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

Re: Trademark Sublicensing Request: DevOps World - Jenkins World

2018-04-04 Thread Kohsuke Kawaguchi

I will be travelling on April 11th, so I asked Tyler to drive this part of
the meeting. My regrets for missing the meeting.

As a board member, given that Jenkins World is an approved name, from the
technical perspective of approving this trademark request, here is my
absentee +1 vote.

On Fri, Mar 30, 2018 at 9:53 AM Kohsuke Kawaguchi <kkawagu...@cloudbees.com>
wrote:

> On behalf of CloudBees, I’d like to request the permission to use the
> following name that uses ‘Jenkins’ in it:
>
>- DevOps World - Jenkins World
>
> This is the new name of the event that we've been calling "Jenkins World", 
> which
> is a previously approved mark
> <https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage>, and
> needless to say, many of you have been there in the past several years. I
> think all the basic considerations led to the approval of Jenkins World
> still applies. I’ve put this up as an agenda for April 11th project
> meeting to be able to get a decision there. If you have any concerns or
> objections, please chime in on this thread prior to the meeting, so that we
> can address them.
>
> Now, related but separately from the trademark sub-licensing request, I
> think this event name change naturally raises the question of "what does
> this change mean?", so let me describe how I see it as positive change.
>
> Over the years, Jenkins has become more and more widespread and mainstream
> in every corner of the software development world. At the same time, the
> problems solved by Jenkins is increasingly seen not as an isolated problem
> of build/test/deploy/etc, but as a part of a bigger problem space of
> Continuous Delivery and DevOps.
>
> The content of the past few Jenkins Worlds reflect this shift. There were
> many deep Jenkins talks that were very popular, like this
> <http://sched.co/Bk3r> or that <http://sched.co/ALPK>, but there are also
> other great sessions that discussed this broader problem space, like this
> <http://sched.co/BZPU> or that <http://sched.co/Bvtv>.
>
> So in order for the name to represent the substance more accurately, as
> the event producer, CloudBees decided that it would like to rename the
> event to “DevOps World - Jenkins World.” This way, the event can appeal to
> both those who are deep in Jenkins and those who are approaching this more
> broadly. It will help Jenkins be seen as the key piece of this landscape
> for the latter audience. While the word “DevOps” might feel ambiguous and
> fuzzy for those of us deep in technology, the event team has done various
> research to conclude that it is used more and to refer to this broad area
> than other terms, thereby making it the best choice. There are some other
> conferences that follow similar "AX - BX" naming patterns, like this one
> <https://www.cloudendure.com/events/dataworks-summit-and-hadoop-summit-berlin-germany-2018/>,
> presumably for similar reasons.
>
> In terms of how the event will be actually produced, I have heard that it
> will not be that different from Jenkins World 2017. There will be one
> ticket, one event venue, one set of keynotes, and one exhibit space. There
> will be session tracks who are marked as Jenkins, DevOps, etc. And of
> course there will be marked community space. A few weeks back, Alyssa,
> Mark, Liam, Tyler, myself and a few others spent some time brainstorming
> what other interesting things we can do this year.
>
> I think Jenkins World remains one of those cases where the interest of the
> community and the interest of the event producer (CloudBees and other
> sponsors) are well aligned. The developer community benefits from having a
> get together and a place where we can interact with users. The user
> community benefits from the learning. And CloudBees and other sponsors
> benefit from being in front of those people. I think this name change will
> help us draw an even bigger crowd and in their eyes signify the key role
> Jenkins plays in this space, which I think will only make this event even
> more valuable.
> --
> Kohsuke Kawaguchi
>
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4xe3PgrVMUrq7ydc%3D-u0J93HXBHh%2B4iV6sVSeHjSG3OTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

2018-04-03 Thread Kohsuke Kawaguchi

Hi, Thomas,

Tyler passed me a link to your project
https://github.com/tomwillfixit/jenkinless, which is in a similar space
with my project of the day called Jenkinsfile Runner.

I haven't studied your project carefully yet, but I already see some
interesting ingredients like memcached that I have no idea what you use it
for :-)   I'd love to hear from you the philosophy & use cases that led to
it. And I'd also love to hear what you think of Jenkinsfile Runner. I think
we have similar interests here, are there any opportunity to collaborate?

On Thu, Mar 1, 2018 at 11:23 AM Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

> And of course I forgot to have the link to the project!
> https://github.com/kohsuke/jenkinsfile-runner
>
>
> On Thu, Mar 1, 2018 at 11:22 AM Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> Kohsuke Kawaguchi
>>
> --
> Kohsuke Kawaguchi
>
-- 
Kohsuke Kawaguchi

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

Re: POTD: Jenkinsfile Runner

It's pretty cool that it actually works, huh?

On Mon, Mar 12, 2018 at 10:57 PM Michael Neale <mne...@cloudbees.com> wrote:

> As an example of how to use (abuse?) this:
>
> I was able to take a container with the set of "recommended" plugins, and
> run it on the "codeship pro" service (which uses docker):
> https://github.com/michaelneale/codeship-jenkinsfile
>
>
>
> On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> Kohsuke Kawaguchi
>>
> --
> 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/e1613f77-8bb0-4d88-91a3-e2dea440444c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/e1613f77-8bb0-4d88-91a3-e2dea440444c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: POTD: Jenkinsfile Runner

On Sun, Mar 11, 2018 at 6:43 AM <johan...@schnatterer.info> wrote:

> From a user perspective, I like your idea of a
> "pipeline.sharedlibrary.test" step and/or a "run-pipeline" CLI command.
> They would definitely solve configuration issues with plugins, docker, etc.
> Now, Jesse mentioned some implementation challenges in his post from Wed,
> 07 Mar 2018 13:04:46
> <https://groups.google.com/d/msg/jenkinsci-dev/gjz3CDhi-kk/yLIqqVGrAQAJ>,
> that I can't comment on, because I'm not that deep into Jenkins internals
> (yet?).
>
> In the meantime, Jesse also provided a workaround for loading a "local"
> shared lib <https://stackoverflow.com/a/49112612/1845976>. With this I
> implemented my first (very simple) integration test
> <https://github.com/cloudogu/ces-build-lib/blob/cd08237a19380b52279f7bd596ab6ff492bea06a/test/it/com/cloudogu/ces/cesbuildlib/Sh/Jenkinsfile>
> and run it successfully from the Jenkinsfile of the shared lib
> <https://github.com/cloudogu/ces-build-lib/blob/feature/integration-test-POC/Jenkinsfile#L87>
> 
>

Nice!

You meant asserts should already work? How would you do those in that
> scenario?
>

I was thinking you'd just put assert statements into Jenkinsfile and that
should already work. Granted, I haven't tried it so maybe it doesn't work.

This approach has of course the limitations we talked about, regarding the
> Jenkins configuration .
> In addition these tests would only be run on Jenkins and not when running
> the build locally with Maven.
>

I'm not sure if I follow you here. The two approaches that I was thinking
about were:

   - "Jenkinsfile Runner" that runs embedded Jenkins locally and runs
   Jenkinsfile in there
   - "run-pipeline CLI command" that submits Jenkinsfile into an existing
   Jenkins server and run it there and send the result back

"pipeline.sharedlibrary.test" is just a pipeline step that runs tests in
some form. In each of the above two versions we can think of their
corresponding "pipeline.sharedlibrary.test" step.


> So right now, I think a better approach would be to provide a Java library
> that allows for running Jenkinsfiles.
> It could be used to implement e.g. JUnit tests that are run by build tools
> such as maven locally (e.g. with the failsafe plugin) and in the same way
> in the Jenkinsfile.
> This library could abstract from the concrete execution with could either
> be
> - Jenkinsfile runner with local plugin folder
> - Jenkinsfile runner in Docker
> - "pipeline.sharedlibrary.test" step
> - a "run-pipeline" CLI command.
>

I was kind of trying to avoid doing 4 different things that each has
different unique trade-offs that only Jenkins experts would understand.

You have mentioned two primary use cases for you, pipeline development and
shared library development. I think we can find one solution that works for
those two cases. I just need to think about this.

The downside would be that such an implementation wouldn't be trivial. And,
> unfortunately, I can't invest to much of my free time right now.
>

Your feedback has been very helpful, and I appreciate the time you are
investing in those.


>
> Am Dienstag, 6. März 2018 22:23:26 UTC+1 schrieb Kohsuke Kawaguchi:
>>
>>
>>
>> On Sun, Mar 4, 2018 at 8:13 AM <joha...@schnatterer.info> wrote:
>>
>>> I think Jenkinsfile Runner brings a lot of opportunities for pipeline
>>> developers. The most obvious ones to me are
>>>
>>>1. Pipeline development (Jenkinsfile)
>>>2. Shared library development
>>>
>>> *Pipeline development*
>>>
>>> Right now (as described by others in this thread) pipeline development
>>> is either a loop of committing / fixing pipelines on production Jenkins,
>>> using pipeline replay on production Jenkins or setting up a local instance
>>> manually.
>>>
>>> With Jenkinsfile Runner we can get faster feedback without polluting our
>>> commit or Jenkins build history and don't have to set up a local instance
>>> manually.
>>>
>> Right. I think we all get this basic picture. Details are where things
>> get interesting!
>>
>> *Shared library development*
>>>
>>> Shared library development right now works much in the same as pipeline
>>> development, except that you have the library code and another (often
>>> production) Jenkinsfile to maintain, in order to try out (as opposed to
>>> automatically test) your Jenkinsfile.
>>> For shared libraries, we thankfully already have JenkinsPipelineUnit,
>>> that makes it easier to implement some tests. However, (as also m

Re: POTD: Jenkinsfile Runner

On Wed, Mar 7, 2018 at 1:04 PM Jesse Glick <jgl...@cloudbees.com> wrote:

> On Tue, Mar 6, 2018 at 4:23 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> > I have another idea. Instead of
> > running Jenkinsfile in this CLI and try to emulate your Jenkins instance
> as
> > closely as possible (in terms of configuration), we could just run
> > Jenkinsfile in the current Jenkins, in a place that nobody else can see.
>
> In principle this is possible, by defining a new implementation of
> `FlowExecutionOwner` that is not based on a `Run`. We have in the past
> discussed the possibility of a Pipeline equivalent to the `/script`
> console.
>

Thanks for the tip. I was actually thinking about creating a full blown
WorkflowJob that's just so happen to be invisible to anyone. Do you think
that would work better/worse?

I doubt this would be a very satisfactory solution to the use case at
> hand, though. Any step which required a `Run` context (either
> mandatory, as in `StepDescriptor.getRequiredContext`, or optionally,
> by checking for null from `StepContext.get(Run.class)`) would either
> fail or behave in some reduced capacity. If you took care to only
> write `Jenkinsfile`s that just used `node` and `sh` and the like and
> none of these features, then fine. But a lot of common functionality
> does assume it has a `Run` context: anything that looks up
> folder-scoped environment variables or credentials; `junit`,
> `milestone`, `lock`, `stash`; everything based on `SimpleBuildStep` or
> `SimpleBuildWrapper`…a lot. You could create a temporary `WorkflowJob`
> in the same folder and hack around with access control so that it is
> only visible to the invoking user, which would let most of these
> things work (probably with some specialized support for branch
> projects), but this seems like it is asking for trouble.
>

IIUC, creating invisible WorkflowJob would bypass these problems.

I think it would be far more practical to work with the existing
> Replay feature, which was designed for precisely this use case. If the
> main objection to using Replay is that you do not want these
> experimental builds to “pollute” the general build history, then we
> can do some minor UI work (for example in Blue Ocean) to hide these
> build records by default. There is already a plan to do something very
> similar for restarted stages (JENKINS-48643). We could even stream the
> build log to the CLI command (JENKINS-33438) and then add an option to
> delete the build as soon as it completes—a very simple and safe
> feature.
>

Ah, so instead of invisible WorkflowJob, we create invisible WorkflowRun,
right?
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4zn1XtZrYY5O6CVe_Kzk%3DL%3Dga%2BBUE_ZvHmtMVYAFES3RQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

Sorry for the bit of delay to come back to this,

On Wed, Mar 7, 2018 at 5:46 AM Bill Dennis <bill.den...@gmail.com> wrote:

> Kohsuke  - some more answers to your questions inline below.
>
> Also I thought of these other things on my walk to the office this morning
> that might be of interest:
>
> - Parameters to jobs : most of my pipeline jobs have parameters defined
> inside. Would the Jenkinsfile Runner have a way to pass in parameters so it
> doesn't just use default values?
>

Ah, good catch, this is actually pretty easy to do. Tracking it as #13
<https://github.com/kohsuke/jenkinsfile-runner/issues/13>.

- Environment values for jobs: For our pipeline automation deployments, we
> set "env" values (key value pairs as strings) at the gobal of folder level
> (using Jenkins Enterprise Folders plugin) and these define some environment
> for jobs (things like REST endpoints to some RESTful services we use in the
> jobs, for example). With the Jenkinsfile Runner have a way to supply this?
>

The global settings, I put that into the class of problems to be solved by
config-as-code, along with plugin installations.

The folder level things, I haven't thought about. Solving the general case
of this is bit involving.

- Script approvals : I have mentioned this below, but some way to define
> script approvals or get the required approvals would help possibly. I know
> if you are hitting script approvals, then probably trying to do too much in
> the pipeline code but it is easy to hit this with simple stuff like Java
> date functions or JSON parsing.
>

I guess the idea here is that you want Jenkinsfile Runner to run the
pipeline with exactly the same script approval settings.

I wonder if it'd be nice if Jenkinsfile Runner can do something like the
permissive mode of SELinux
<https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing>,
where it runs your pipeline entirely and spit out the approvals it needed?
That way you don't need to do any trial & error on production Jenkins.

- Jenkinsfile As a Service idea (JFAAS?): you mentioned this and I really
> like this idea. The possibility to externally run a Jenkinsfile supplied
> and get back some results like build artifacts and console output without
> having any jobs or builds appear on the Jenkins master or needing a job
> configuration. The reason is we tend to think about loading all our
> automation into Jenkins. But our world is not all inside Jenkins and we
> have other automation solutions that can have extensions and customisation.
> An example is some of our custom services we build and some off the shelf
> stuff like the Serena Business Process management server we have. But
> Jenkins is really good and doing some automation, tooling and spinning /
> scaling up agent workers in Docker etc, so it would be good to use that
> from these other services by having them send a Jenkinsfile they own over
> and getting some results back somehow. Maybe this is something different
> from Jenkinsfile Runner though.
>

Yeah, as you nailed it, JFaaS idea is around being able to submit the work
and spin up the process to execute it, and store the result somewhere,
which you can later browse. There's a bit of similarity to build publisher
plugin <https://wiki.jenkins.io/display/JENKINS/Build+Publisher+Plugin>.

Obviously, Jenkinsfile Runner alone is not going to be able to do that, but
the point of it is so that we can talk about it more concretely, like we
are doing it here.

I'm not sure if I fully grok the portion where you say "But our world is
not all inside Jenkins and we have other automation solutions that can have
extensions and customisation. An example is ... Serena Business Process
management server."

Can you help me understand how those tools and your custom stuff work
together in your environment? If you need to get to sensitive stuff, I'm
happy to jump onto a call, especially given that you appear to be a
CloudBees customer :-)

>
> Best regards,
> --Bill
>
> On Tuesday, 6 March 2018 21:33:37 UTC, Kohsuke Kawaguchi wrote:
>
>>
>> On Tue, Mar 6, 2018 at 2:57 AM Bill Dennis <bill@gmail.com> wrote:
>>
>>> Thanks Kohsuke, I tried to give some answers to your questions inline
>>> below, if I didn't mess up the reply..
>>>
>>> Bill
>>>
>>> On Friday, 2 March 2018 17:57:24 UTC, Kohsuke Kawaguchi wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis <bill@gmail.com> wrote:
>>>>
>>>>> Hello Kohsuke -
>>>>>
>>>>> I am a developer using Jenkins pipeline quite lot where I work.
>>>>>
>>>>> We are using Jenkins pipelines in two scenarios:
>>

Re: Evergreen packaging for Jenkins Essentials

2018-03-20 Thread Kohsuke Kawaguchi

I've assigned Tyler as the BDFL delegate of this JEP-301, given that I
consider him the leader of this effort.

On Thu, Feb 15, 2018 at 9:45 AM R. Tyler Croy <ty...@monkeypox.org> wrote:

> (replies inline)
>
> On Thu, 15 Feb 2018, Carlos Sanchez wrote:
>
> > yay! +1
> >
> > I agree with previous comments that it is not ideal to run multiple
> > processes and that in a kubernetes world this would possibly be a Pod
> with
> > two containers, but I think it's important to get something out and
> > iteratively improve.
> > A decent user experience today means just one container and we can always
> > had a Pod definition for Kubernetes users if we find that useful in the
> > future.
> >
> > Regarding different environment autodetection it would be nice, but
> having
> > a way to manually select it (system property, env var,...) would be good
> > enough for now
>
> Contemplating jglick's feedback further, I am more in agreement with his
> point
> about providing disparate "flavors" to tailor the experience further for
> user-success on cloud environments such as Azure or AWS. To that end I've
> updated JEP-300: https://github.com/jenkinsci/jep/pull/58
>
> The detail which makes this important is the suite of plugins necessary to
> include "out of the box" to provide the Automatic Sane Defaults will change
> depending on the environment. If we can detect AWS, then we can make sure
> we're
> downloading the S3 plugin, for example, but on Azure we wouldn't want to
> bloat
> the user's environment with it. Rather, Azure users should have the Azure
> VM
> Agents and Azure Container Agents plugin included by default.
>
>
> I will target AWS with the first "flavor" and then we can see where that
> takes
> us.
>
>
>
> Thanks for the feedback Carlos!
>
>
>
> Cheers
> - R. Tyler Croy
>
> --
>  Code: <https://github.com/rtyler>
>   Chatter: <https://twitter.com/agentdero>
>  xmpp: rty...@jabber.org
>
>   % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
> --
>
> --
> 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/20180215174522.ewqpuvbmjxchuj3j%40blackberry.coupleofllamas.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: first draft of a new JEP: Jenkins X: Jenkins for Kubernetes CD

2018-03-14 Thread Kohsuke Kawaguchi

Thanks James,

This is an important and exciting JEP for me, because it sets the mission &
scope for a new project “Jenkins X.”
Starting from Jenkins 2, in contributor events and Jenkins Worlds, I’ve
always pitched that our Jenkins project needs to take a bigger role and
responsibility in serving our users and solving their challenges.
Historically, by and large we did it by writing plugins, but we’ve been so
successful in doing that, now we need to create solutions that combine
those plugins.

I said “starting from Jenkins 2” because the default recommended set of
plugins, initial setup wizard to start Jenkins more securely, and so on was
the first step toward us doing more than writing plugins.

Blue Ocean followed, in which we focused on important parts of Jenkins and
provided great UX for that. It decidedly blended together feature areas
that are internally provided by a whole bunch of different plugins, but
users see much less seam between them now.

Jenkins Essentials, which Tyler posted in recent weeks, is one more step
forward. That project is aiming to take an even bigger responsibility in
keeping people’s Jenkins instances up and running, and further de-emphasize
individuality of plugins and emphasize the combined solution.

I see Jenkins X very much on this same path. Jenkins X brings a different
aspect to building a solution — it focuses on a specific vertical area, a
Kubernetes application development, and really drastically simplify the
software development by bringing together Jenkins, a whole bunch of
plugins, the opinionated best practice of how you should use Kubernetes.

Especially early in the days of Jenkins, this kind of integration was done
by heroic Jenkins admins and provided for the organizations they were
working in, but they were never really shared upstream in the community. So
we all had to re-invent that.

Jenkins X is a significant step because it is trying to bring those
hard-earned integration work back into the community. It makes Jenkins
approachable and valuable to a whole new set of users who are not currently
using Jenkins.

>From that perspective, I hope more projects like this will follow, in
different domains of software development. This is a little bit like how
Eclipse has evolved from just a Java IDE to an umbrella of projects.

On top of all that, the icing on the cake, or the main cake, depending on
who you are, is that Kubernetes application development is a very exciting
area of technology where there’s a lot of interest. I’m sure many of you
are already doing that or thinking about doing that, and so this project
should be useful to many folks.

I know James has a lot of ideas of what he can do on Jenkins X, and I also
fundamentally believe that a lot of good ideas also come from outside. So
please help James and his team build a better software by participating in
the effort. If you don't feel like you don't have any specific point to
make, even just providing them an encouragement would help them feel good
to press forward in the current direction. That's an useful feedback on its
own.

I hope we’ll see a very lively discussion.

On Fri, Mar 9, 2018 at 11:08 AM Liam Newman <bitwise...@gmail.com> wrote:

> Thanks, James!
>
> This has been approved as Draft.  Going forward the current version can be
> viewed here:
> https://github.com/jenkinsci/jep/blob/master/jep/400/README.adoc
>
> Please continue to discuss in this droup and submit pull requests as
> needed.
>
> Thanks,
> Liam Newman
> JEP Editor
>
>
> On Friday, March 9, 2018 at 2:18:24 AM UTC-8, James Strachan wrote:
>
>> I've just submitted a draft of a new JEP:
>> https://github.com/jenkinsci/jep/pull/62
>>
>> You can read the JEP in full here:
>> https://github.com/jstrachan/jep/blob/jx/jep/400/README.adoc
>>
>> I hope this makes sense & some of you find it interesting. I'd love
>> feedback if anyone has any!
>>
>> I'll try blog more about it next week to give a more complete picture of
>> the current functionality in the current prototype.
>>
>> --
>>
> James
>> ---
>> Twitter: @jstrachan
>> Email: james.s...@gmail.com
>> Blog: https://medium.com/@jstrachan/
>>
>> --
> 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/1500b5bd-d320-4551-aa5c-3f2036ea6403%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/1500b5bd-d320-4551-aa5c-3f2036ea6403%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--

Re: Trademark sublicense request: CloudBees Jenkins Metrics

2018-03-08 Thread Kohsuke Kawaguchi

I think the presence of the "CloudBees" as a prefix has such overriding
clarity in terms of the origin of the effort, that I'm having hard time
imagining that creates a confusion in that regard. It is true that they
share the same "Metrics" part, but that's not the trademarked part.

That said, I inquired on this point and I learned that it is technically
true that there exists a jpi file whose display name is "CloudBees Jenkins
Metrics plugin."

But Metrics plugin and CloudBees Jenkins Metrics operate on different
planes. Metrics plugin is a library plugin, and it's by and large relevant
only for those who "open the engine room." CloudBees Jenkins Metrics is a
feature of a product that show up in brochures and collateral. It's a
little bit like workflow-*-plugin and Pipeline. The former is a unit of
distribution and development and a concern to contributors, the latter is a
unit of feature and a concern to users.

In addition to that, CloudBees Jenkins Metrics plugin is not distributed
the same way Metrics plugin is. The former is a restricted access plugin
that's only available to customers, and the latter is a plugin that's on
the community update center.


On Thu, Mar 8, 2018 at 6:41 AM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I personally find that the proposed name could cause confusion with the
> Metrics plugin, however given that the Metrics plugin was developed on
> company time, I feel it would be disingenuous of me to leverage a
> side-effect of being paid to do that development that has resulted in me
> being the maintainer of the plugin in order to apply my personal opinions
> to the same company.
>
> In any case, as an employee of CloudBees, I feel I have to recuse myself
> from the debate.
>
>
> On Thursday, 8 March 2018 12:46:22 UTC, Oleg Nenashev wrote:
>>
>> Generally the request looks good to me.
>> OTOH it would be great to get feedback from the maintainer of the Metrics
>> Plugin <https://wiki.jenkins.io/display/JENKINS/Metrics+Plugin> (Stephen
>> Connolly?).
>> If CloudBees plans to release a "CloudBees Jenkins Metrics Plugin" as a
>> part of this new product, it may cause some confusion.
>>
>> BR, Oleg
>>
>> On Wednesday, March 7, 2018 at 5:29:40 PM UTC+1, Kohsuke Kawaguchi wrote:
>>>
>>> On behalf of CloudBees, I’d like to request the permission to use the
>>> following name that uses ‘Jenkins’ in it:
>>>
>>>- CloudBees Jenkins Metrics
>>>
>>> To help people understand how this name is going to be used, let me
>>> describe a bit about the effort for which we’d like to use this name.
>>>
>>> Back several years ago, we have requested the sublicense to use
>>> ‘CloudBees Jenkins Analytics,’ which was subsequently approved
>>> <https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage>. It
>>> is a feature that is a part of our products. It has evolved since then, and
>>> we’d like to give it a new name to more accurately reflect what it is.
>>>
>>> When we look at name approval requests like this, a key criteria is to
>>> make sure it doesn’t create confusion about the origin of the effort. From
>>> that perspective, this name has ‘CloudBees’ clearly in front of it, and it
>>> is consistent with other names that are already approved. The situation and
>>> the considerations that led to the approval of the past requests hasn't
>>> really changed, so I hope the new name doesn’t raise any eyebrows and
>>> result in a smooth approval.
>>>
>>> I’ve put this up as an agenda for Mar 14th project meeting to be able to
>>> get a decision there. If you have any concerns or objections, please chime
>>> in on this thread prior to the meeting, so that we can address them.
>>>
>>> --
>>> Kohsuke Kawaguchi
>>>
>> --
> 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/a24547c6-32e1-4a75-9fc9-a1666ef8cf5a%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a24547c6-32e1-4a75-9fc9-a1666ef8cf5a%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Trademark sublicense request: CloudBees Jenkins Metrics

2018-03-07 Thread Kohsuke Kawaguchi

On behalf of CloudBees, I’d like to request the permission to use the
following name that uses ‘Jenkins’ in it:

- CloudBees Jenkins Metrics

To help people understand how this name is going to be used, let me
describe a bit about the effort for which we’d like to use this name.

Back several years ago, we have requested the sublicense to use ‘CloudBees
Jenkins Analytics,’ which was subsequently approved
<https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage>. It is a
feature that is a part of our products. It has evolved since then, and we’d
like to give it a new name to more accurately reflect what it is.

When we look at name approval requests like this, a key criteria is to make
sure it doesn’t create confusion about the origin of the effort. From that
perspective, this name has ‘CloudBees’ clearly in front of it, and it is
consistent with other names that are already approved. The situation and
the considerations that led to the approval of the past requests hasn't
really changed, so I hope the new name doesn’t raise any eyebrows and
result in a smooth approval.

I’ve put this up as an agenda for Mar 14th project meeting to be able to
get a decision there. If you have any concerns or objections, please chime
in on this thread prior to the meeting, so that we can address them.

--
Kohsuke Kawaguchi

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

Re: POTD: Jenkinsfile Runner

On Tue, Mar 6, 2018 at 2:57 AM Bill Dennis <bill.den...@gmail.com> wrote:

> Thanks Kohsuke, I tried to give some answers to your questions inline
> below, if I didn't mess up the reply..
>
> Bill
>
> On Friday, 2 March 2018 17:57:24 UTC, Kohsuke Kawaguchi wrote:
>
>>
>>
>> On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis <bill@gmail.com> wrote:
>>
>>> Hello Kohsuke -
>>>
>>> I am a developer using Jenkins pipeline quite lot where I work.
>>>
>>> We are using Jenkins pipelines in two scenarios:
>>>
>>>- For CI building and testing some of our internal components (what
>>>Jenkins is traditionally used for)
>>>- For running / orchestrating complex automation processes (so
>>>Jenkins is talking to some external systems using SOAP / REST etc) via
>>>tooling and even directly via REST using plugins.
>>>
>>> I have mostly used JenkinsPipelineUnit for testing / validation of the
>>> pipelines and I have been looking into the direct / live approach that Oleg
>>> demonstrated (running Jenkins locally in Docker and getting the pipeline
>>> being developed direct from a host file system volume mount).
>>>
>>> I think Jenkinsfile Runner would be really useful for developers who
>>> don't need or want the overhead of developing tests with
>>> JenkinsPipelineUnit. I have worked with some developers wanting to develop
>>> Jenkinsfiles for their CI process and the main problem is knowing if the
>>> Jenkinsfile will work when they commit it to the repo. They go round this
>>> loop of commit / fix running in the production Jenkins or using the Jenkins
>>> pipeline "replay" feature. It can be a painful process if you are not
>>> familiar with Jenkins pipeline and Groovy syntax!
>>>
>>
>> This kind of context is really helpful. Thank you!
>>
>
> Happy to feedback. Thanks for Jenkins and pipeline as code, it helped me
> deliver some projects with Jenkins in a way that I thought would not be
> possible a few years ago.
>

My pleasure, and really the portion I can take credit for is getting
smaller every day!


>
>
>> I think some things to consider are:
>>>
>>> - How does the Jenkins Runner replicate the agents / slaves identifiers
>>> on the target Jenkins?
>>> - How to deal with tooling on the target Jenkins (custom tools, JDKs,
>>> Gradle, etc)?
>>>
>>
>> Right, I guess your point is that Jenkinsfile Runner should aim to run
>> Jenkinsfile in much more realistic setup, and that doesn't stop at using
>> real Jenkins and real Pipeline plugins, but it also needs to include other
>> configurations of Jenkins. I think Jesse made a similar observation. I have
>> a few thoughts:
>>
>>- Configuration-as-code
>><https://github.com/jenkinsci/configuration-as-code-plugin> could
>>play a role here in terms of letting people define the configuration of
>>Jenkins once and use it both in production and in setup like Jenkinsfile
>>Runner
>>- I'm a fan of making Jenkinsfile itself more portable. For example,
>>if people are already in the mode of using docker images to run builds in,
>>then more of the toolings would be packaged in there, and it should allow
>>Jenkinsfile Runner to run your project in much the same way as your
>>production Jenkins. I'm curious how much of this is already reality vs
>>ideal that people are working toward.
>>
>> Yes, all of this. I have often thought that we need something like
> declarative pipeline for the configuration of Jenkins as code instead of
> going into all those web config pages. Jenkins master as Docker container
> seems good. In our environment we are not currently using Docker but I have
> seen that that is the way to go. Getting a larger organisation to adopt the
> right technology and the associated costs of that is the challenge, so we
> remain using traditional Jenkins slaves and tooling methods. Hopefully
> Dockerised soon. We do use Jenkins Enterprise from CloudBees.
>

"something like declarative pipeline for the configuration of Jenkins as
code instead of going into all those web config pages" --- please do check
out the linked configuration-as-code effort. I think you'll love it.

And thanks for the explanation of the state of your current Jenkins master.

I think the perfect Jenkinsfile Runner for me would provide:
>>>
>>> - Somehow capture the plugins, tooling and agents on our production
>>> Jenkins
>>> - Validate the Jenkinsfile pipelin

Re: POTD: Jenkinsfile Runner

Oleg gave us the fix, which I merged to the master just now. I think
that'll fix the problem.

On Tue, Mar 6, 2018 at 1:22 AM Michael Neale <mne...@cloudbees.com> wrote:

> Trying this out, looks like I am hitting JEP-200:
>
> https://jenkins.io/redirect/class-filter/
>
> Need to dig in further (I thought I tried the same version of Jenkins as
> you). Anyone else seen this?
>
>
>
> java.lang.UnsupportedOperationException: Refusing to marshal
> io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons;
> see https://jenkins.io/redirect/class-filter/
> at
> hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
> at
> com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
> at
> com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
> at
> com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
> at
> com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
> at
> hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
> at
> hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
> Caused: java.lang.RuntimeException: Failed to serialize
> hudson.model.Actionable#actions for class
> org.jenkinsci.plugins.workflow.job.WorkflowRun
>
>
> On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> Kohsuke Kawaguchi
>>
> --
> 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/3836b845-5e9f-44d6-883d-10caf7e78832%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/3836b845-5e9f-44d6-883d-10caf7e78832%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

-- 
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/CAN4CQ4xs-Y3WQ365CXpeORMyo%2BL-uMScPof2FqMCzv%3DxWx7eqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: POTD: Jenkinsfile Runner

gt;.
>
> Good point.


> Once those issues are solved, we'll have a very basic way of automating
> integration tests for shared libraries by executing IT Jenkinsfiles from
> the shared libraries pipeline and failing the build if the IT fails.
>

That'd be really cool, isn't it!?

> Of course, this would be very basic testing. For more sophistiated testing
> we would want to
>
>
>- trigger the ITs from maven or gradle,
>- use asserts,
>- get the results as JUnit XML.
>
> So, yes, we're not there yet. But we now have a foundation to build all
> this upon.
>

asserts would already work, right? It seems like we can do that relatively
easily on its own.

But with that aside, I think I understand the picture in your head. You are
really approaching it like Maven plugin development. Indeed this would help
illustrate relative strength of both JenkinsPipelineUnit and "integration
tests"


>
> Thanks for that & best regards,
>
> Johannes
>
>
> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> Kohsuke Kawaguchi
>>
>
>
> Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
>>
>> Jenkinsfile Runner is an experiment to package Jenkins pipeline execution
>> as a command line tool. The intend use cases include:
>>
>>- Use Jenkins in Function-as-a-Service context
>>- Assist editing Jenkinsfile locally
>>- Integration test shared libraries
>>
>> Over the past year, I've done some deep-dive 1:1 conversations with some
>> Jenkins users and I felt something like this might move the needle for them
>> in an important way.
>>
>> I'd love to hear any reactions on your side. Could something like this be
>> important for you, does it miss any key points for you? If you mentally
>> picture a perfect version of this, what would that do, and how would you
>> use?
>>
>> Let me know!
>>
>> --
>> Kohsuke Kawaguchi
>>
> --
> 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/fcdcb7e4-f6ca-4ec5-bf7d-0c9ca32618ee%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/fcdcb7e4-f6ca-4ec5-bf7d-0c9ca32618ee%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Kohsuke Kawaguchi

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

Re: POTD: Jenkinsfile Runner