Re: Any plans for the github checks API?

[Ullrich Hafner]

Ah, I already added you ;-)

https://docs.google.com/document/d/1fl3sF0mArtv2THOjPSZvNufGme4P24BtT0BirHMeMRY/
 


Feel free to run away...

> Am 31.01.2020 um 17:32 schrieb Jon Brohauge :
> 
> Leave it to Oleg to save my a** ;-)
> 
> On Thursday, January 30, 2020 at 5:16:45 PM UTC+1, Oleg Nenashev wrote:
> I would join as mentor as well
> 
> On Thu, Jan 30, 2020, 17:05 Jon Brohauge > wrote:
> This is something I'd love to see get accepted into GSoC 2020. I'd even 
> volunteer being a mentor for this. Although a more technical mentor would 
> probably be needed alongside.
> 
> Rgds,
> Jon
> 
> On Wednesday, January 29, 2020 at 11:23:31 AM UTC+1, Ullrich Hafner wrote:
> I started a document for the project idea:
> https://docs.google.com/document/d/1fl3sF0mArtv2THOjPSZvNufGme4P24BtT0BirHMeMRY/edit?usp=sharing
>  
> 
> 
> Feel free to extend or comment.
> 
>> Am 28.01.2020 um 13:12 schrieb Oleg Nenashev >:
>> 
>> + Ullrich Hafner who was interested to write up a project idea for this 
>> topic.
>> I would be happy to be a mentor there, and I believe we could find more 
>> mentors to make it happen
>> 
>> 
>> On Mon, Jan 27, 2020 at 5:55 PM Sladyn Nunes > wrote:
>> +1 
>> "ChatOps" triggers would be highly beneficial thereby letting the 
>> github-branch-source to run the required checks on specific parts. Also 
>> detailed reports from GitHub Checks could be published and maybe parsed as 
>> required.
>> 
>> 
>> On Mon, Jan 27, 2020, 6:27 PM Oleg Nenashev > wrote:
>> Just to bump this thread, we consider adding Checks API integration as a 
>> GSoC 2020 project idea.
>> We had a preliminary discussion with Ulli Hafner (Warnings NG) and other 
>> parties.
>> 
>> If someone is interested to join the project, please let me know
>> 
>> On Thursday, May 10, 2018 at 5:56:28 PM UTC+2, Jesse Glick wrote:
>> On Thu, May 10, 2018 at 5:37 AM, Steven F > wrote: 
>> > The examples in the article show elements such as linting, 
>> > build, static analysis as separate and individually runnable things. In 
>> > Jenkins 2.x Pipeline it feels like bundling these things together is more 
>> > encouraged. 
>> 
>> Well, it is generally more straightforward to have those things be run 
>> as part of a single Jenkins build, triggered by SCM changes. What is 
>> missing is an API which would allow Jenkins report plugins (`Publisher 
>> & SimpleBuildStep`, for example) to indicate to the system that there 
>> is some information to be displayed in an abstract “change request”, 
>> perhaps associated with source code lines, which would then be 
>> implemented by `github-branch-source` with the Checks API. 
>> 
>> jxpe...@godaddy.com <> wrote: 
>> > just rerunning the job from github would save a step 
>> 
>> See JENKINS-45455 for rerunning generally; again we would need a new 
>> API to allow this is to be integrated with in-PR “chatops” triggers, 
>> so that `github-branch-source` could receive GH events and refire them 
>> as requests to rerun parts of a build, which 
>> `pipeline-model-definition` would then interpret as a Declarative 
>> build trigger. 
>> 
>> All this would allow you to do more from GitHub and less from Blue 
>> Ocean or the Jenkins “classic” UI. @abayer has done the most work in 
>> this area and should probably be commenting. 
>> 
>> -- 
>> 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/8215b84f-fd28-4066-a8d6-473683a43282%40googlegroups.com
>>  
>> .
>> 
>> -- 
>> 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/UGhDM5lcz8Y/unsubscribe 
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkin...@googlegroups.com <>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqttb4%3DVhSnd%3DKLeq69GioC4mzmpyadcJUG0gdX9TN%3DbOw%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> 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/U

Re: PROPOSAL: Remove network discovery services

[Matt Sicker]

On Fri, Jan 31, 2020 at 3:35 AM Amit Dar  wrote:
> As a heavy Swarm Plugin user, I can say we don't use the discovery feature of 
> the plugin, but rather direct the client to a specific master. This is due 
> the fact we have several Jenkins masters in the same network (for testing 
> purposes, mainly). I think the usage of the auto discovery feature is 
> something people use only if they have a single instance of the master in 
> their network, and this might be true only when using jenkins in a 
> "dockerized" network.

Agreed on this regard. I used to use the multicast discovery feature
of Hazelcast long ago when we had only one cluster, but once we added
another cluster that was logically a different environment but still
accessible within the same network, this caused numerous configuration
issues and mixing of caches and other nonsense. I highly suggest
leaving UDP multicast to be used only for video streaming or the other
goals it was originally designed for.

-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
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/CAEot4oxNGpF6%2Bm7%3DUCbH%3D6N98B18snKOcSr%2BRji0vtn2_cTYBA%40mail.gmail.com.

Re: Any plans for the github checks API?

[Jon Brohauge]

Leave it to Oleg to save my a** ;-)

On Thursday, January 30, 2020 at 5:16:45 PM UTC+1, Oleg Nenashev wrote:
>
> I would join as mentor as well
>
> On Thu, Jan 30, 2020, 17:05 Jon Brohauge > 
> wrote:
>
>> This is something I'd love to see get accepted into GSoC 2020. I'd even 
>> volunteer being a mentor for this. Although a more technical mentor would 
>> probably be needed alongside.
>>
>> Rgds,
>> Jon
>>
>> On Wednesday, January 29, 2020 at 11:23:31 AM UTC+1, Ullrich Hafner wrote:
>>>
>>> I started a document for the project idea:
>>>
>>> https://docs.google.com/document/d/1fl3sF0mArtv2THOjPSZvNufGme4P24BtT0BirHMeMRY/edit?usp=sharing
>>>
>>> Feel free to extend or comment.
>>>
>>> Am 28.01.2020 um 13:12 schrieb Oleg Nenashev :
>>>
>>> + Ullrich Hafner who was interested to write up a project idea for this 
>>> topic.
>>> I would be happy to be a mentor there, and I believe we could find more 
>>> mentors to make it happen
>>>
>>>
>>> On Mon, Jan 27, 2020 at 5:55 PM Sladyn Nunes  
>>> wrote:
>>>
 +1 
 "ChatOps" triggers would be highly beneficial thereby letting the 
 github-branch-source to run the required checks on specific parts. Also 
 detailed reports from GitHub Checks could be published and maybe parsed as 
 required.


 On Mon, Jan 27, 2020, 6:27 PM Oleg Nenashev  wrote:

> Just to bump this thread, we consider adding Checks API integration as 
> a GSoC 2020 project idea.
> We had a preliminary discussion with Ulli Hafner (Warnings NG) and 
> other parties.
>
> If someone is interested to join the project, please let me know
>
> On Thursday, May 10, 2018 at 5:56:28 PM UTC+2, Jesse Glick wrote:
>>
>> On Thu, May 10, 2018 at 5:37 AM, Steven F  
>> wrote: 
>> > The examples in the article show elements such as linting, 
>> > build, static analysis as separate and individually runnable 
>> things. In 
>> > Jenkins 2.x Pipeline it feels like bundling these things together 
>> is more 
>> > encouraged. 
>>
>> Well, it is generally more straightforward to have those things be run
>>  
>> as part of a single Jenkins build, triggered by SCM changes. What is 
>> missing is an API which would allow Jenkins report plugins (`Publisher
>>  
>> & SimpleBuildStep`, for example) to indicate to the system that there
>>  
>> is some information to be displayed in an abstract “change request”, 
>> perhaps associated with source code lines, which would then be 
>> implemented by `github-branch-source` with the Checks API. 
>>
>> jxpe...@godaddy.com wrote: 
>> > just rerunning the job from github would save a step 
>>
>> See JENKINS-45455 for rerunning generally; again we would need a new 
>> API to allow this is to be integrated with in-PR “chatops” triggers, 
>> so that `github-branch-source` could receive GH events and refire them
>>  
>> as requests to rerun parts of a build, which 
>> `pipeline-model-definition` would then interpret as a Declarative 
>> build trigger. 
>>
>> All this would allow you to do more from GitHub and less from Blue 
>> Ocean or the Jenkins “classic” UI. @abayer has done the most work in 
>> this area and should probably be commenting. 
>>
>
> -- 
> 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/8215b84f-fd28-4066-a8d6-473683a43282%40googlegroups.com
>  
> 
> .
>

 -- 
 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/UGhDM5lcz8Y/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to 
 jenkin...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAC-Leqttb4%3DVhSnd%3DKLeq69GioC4mzmpyadcJUG0gdX9TN%3DbOw%40mail.gmail.com
  
 
 .
>>>
>>>
>>> -- 
>> 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/UGhDM5lcz8Y/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkin...@googlegroups.com .
>> T

Re: [GSOC 2020 PROJECT IDEA] Jenkins distribution customize service

[Rick]

Hi all,

Here is the Pull Request link
https://github.com/jenkins-infra/jenkins.io/pull/2813.

Please help me to do the review work, of course, any supplements are
welcome.

On Fri, Jan 31, 2020 at 11:22 AM Rick  wrote:

> Hi all,
>
> Thanks for reaching out. Please help me to review my PR once I create it.
> I'll do it today. My daily routine is chaos now due to the virus. More than
> 9k people infected.
>
> On Thu, Jan 30, 2020 at 10:54 PM Jeff  wrote:
>
>> I just saw this, but I would be interested in working with you on this
>> even if it doesn't make it into GSoC.
>>
>> Rick, do you need help getting a proposal started?
>>
>> Best
>> Jeff
>>
>> On Fri, Jan 17, 2020 at 3:31 AM Chris Kilding <
>> chris+jenk...@chriskilding.com> wrote:
>>
>>> The notion of a Jenkins distribution(s) sounds relevant to us.
>>>
>>> In my company we have a central team which is trying to put together a
>>> standardised Jenkins template to deploy on AWS, which all product teams can
>>> then adopt instead of rolling their own. (This is part of a phased
>>> deduplication strategy and isn't the end game: I could perhaps see a
>>> multi-tenant central Jenkins instance for some tasks in the future.)
>>>
>>> The work that the central team does in assembling a set of plugin
>>> versions, configuration etc, certifying that they all work together, and
>>> then repeating this certification when things change, starts to look like
>>> the work that the community around a Linux distro does. But unlike the
>>> Linux community, Jenkins tooling teams can't share the workload with teams
>>> in other places. Each organisation must duplicate the effort of maintaining
>>> their own in-house Jenkins distro, even if a lot of those distros look very
>>> similar to each other. The exception to the rule is Jenkins X for
>>> Kubernetes, but if a company is not in a position to move their CI/CD to
>>> Kubernetes then they're out of luck.
>>>
>>> For example, I suspect that both my company and Jeff's team at GoDaddy
>>> have developed variations on a "Jenkins for AWS" distribution, but we've
>>> reinvented them - and continue to maintain them - independently. If we were
>>> instead to share the work of building a standardised Jenkins for AWS
>>> distro, it might look a bit like this:
>>>
>>> - Start with Jenkins vanilla
>>> - Build in a set of core AWS-specific opinions (build agents must be
>>> spawned on [AWS compute service], logs must be forwarded to [AWS logging
>>> service], credentials must be stored in [AWS secrets service] etc). These
>>> would be the defining characteristics of the distro, something like how
>>> Ubuntu uses Gnome, SystemD etc. All plugins and config required to make
>>> this work would be pre-packed in the distro.
>>> - Still allow users to configure this as they please, or to install
>>> extra plugins etc. This is how they'll customise it to their environments.
>>> The analogy with Ubuntu is that you would expect to install say language
>>> runtimes or apps from the APT repos as those are extras, but you wouldn't
>>> expect to replace the bundled desktop environment (you'd certainly have an
>>> uphill struggle to do it cleanly).
>>>
>>> Anything that would help Jenkins users to reduce duplicated maintenance
>>> effort sounds good in my book. Whether that's a customisation service, or
>>> something more pre-packed equivalent to a Linux distro, or something else,
>>> I don't have a clear picture of yet.
>>>
>>> I suppose the cost/benefit comes down to:
>>>
>>> - How much we can share
>>> - How many teams that use Jenkins are interested in participating
>>> - How difficult it is to build the common packaging tooling (can we do
>>> it in 1 GSoC or is it a bigger thing?)
>>> - Time horizons (do the potential participants foresee sticking with
>>> their Jenkins deployment stack, or something similar to it, for at least N
>>> years such that it's worth putting the effort in)
>>>
>>> Chris
>>>
>>> On Thu, 9 Jan 2020, at 12:36 PM, Daniel Beck wrote:
>>>
>>>
>>> On Wed, Jan 8, 2020 at 3:49 PM Rick  wrote:
>>>
>>> For many users, they download Jenkins first, then select some plugins
>>> and config them. It might take a lot of time, like hours. But if we can get
>>> a perfect Jenkins distribution which contains all we need, it can save that
>>> time for us. Yes, I propose an out of the box solution.
>>>
>>>
>>> Jesse brings up some potential issues with something like this in
>>> https://groups.google.com/d/msg/jenkinsci-dev/8VnvgOVeVIs/7AM6pruADAAJ
>>> -- this could require some work on a fairly badly documented and tested
>>> part of Jenkins core to make work well.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtK6EzOF8ghN1ty

Re: PROPOSAL: Remove network discovery services

[Daniel Beck]

We propose to remove these network discovery services. See
https://issues.jenkins-ci.org/browse/JENKINS-60913 and
https://github.com/jenkinsci/jenkins/pull/4460 .

> Please respond with any agreement or if you have any important
> implementations that require these capabilities. Perhaps if this is still
> needed, the capabilities could be pulled out of core into a plugin,
> maintained by someone that uses it.
>
Clear +1

Since there's no associated data, deleting (perhaps with a warning logged
when the then obsolete system props are set to an "enable" value just to
make sure admins can notice before users) from core seems fine even without
a plugin initially, and certainly no detachment dance.

-- 
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/CAMo7PtLE8%2Bb%2B3AjW4trs3wXFLmK5jXmYtHsYiYAwxjVe_fUmsQ%40mail.gmail.com.

Re: PROPOSAL: Remove network discovery services

[Amit Dar]

Hi,

As a heavy Swarm Plugin user, I can say we don't use the discovery feature 
of the plugin, but rather direct the client to a specific master. This is 
due the fact we have several Jenkins masters in the same network (for 
testing purposes, mainly). I think the usage of the auto discovery feature 
is something people use only if they have a single instance of the master 
in their network, and this might be true only when using jenkins in a 
"dockerized" network.

If you have the capability to understand the usage of the plugin (with or 
without the discovery feature) I suggest you use it to make a better 
decision.



On Thursday, January 30, 2020 at 6:47:55 PM UTC+2, Jeff Thompson wrote:
>
> Hi,
>
> Dating back many years, Jenkins has supported two network discovery 
> services (UDP multicast/broadcast and DNS multicast). When this was first 
> implemented this may have been a reasonable way to provide useful lookup 
> services. With modern Jenkins capabilities, networks, and security 
> considerations, this is no longer a good mechanism. There are now other 
> ways to better accomplish pretty much everything this does.
>
> With Jenkins Security Advisory 2020-01-29 ( 
> https://jenkins.io/security/advisory/2020-01-29/ ) these services were 
> disabled by default because of 
>  SECURITY-1641 / 
> CVE-2020-2100.
>
> The tests for these services have long been problematic because of various 
> system issues. They have never passed for me on my development machine and 
> others have reported the same. The issues are exacerbated with Java 11.
>
> We propose to remove these network discovery services. See 
> https://issues.jenkins-ci.org/browse/JENKINS-60913 and 
> https://github.com/jenkinsci/jenkins/pull/4460 .
>
> Please respond with any agreement or if you have any important 
> implementations that require these capabilities. Perhaps if this is still 
> needed, the capabilities could be pulled out of core into a plugin, 
> maintained by someone that uses it.
>
> Jeff Thompson
>

-- 
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/9ed19efd-a5fa-4264-ab62-1a95a2e5e16c%40googlegroups.com.

Re: JEP-13: timja youtube permissions for JCasc

[Raihaan Shouhell]

+1

On Fri, Jan 31, 2020 at 5:12 PM Tracy Miranda 
wrote:

> +1
>
> On Fri, Jan 31, 2020 at 3:27 AM Mark Waite 
> wrote:
>
>> +1 from me
>>
>> On Fri, Jan 31, 2020 at 9:22 AM Tim Jacomb  wrote:
>>
>>> Hi
>>>
>>> As a sub-project leader for JCasc I'm requesting permission to upload
>>> videos to the jenkinsci youtube channel for JCasC sub-project meetings
>>>
>>>
>>> https://github.com/jenkinsci/jep/blob/master/jep/13/README.adoc#eligibility
>>>
>>> I have a signed ICLA:
>>> https://github.com/jenkinsci/infra-cla/tree/master/collected/icla/timja
>>> and my google account has 2fa on it
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> 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/CAH-3BieuhqJAAcDMC%3Dz-OcvkG26z3exQERTpvw1uxZ_4MKfmAQ%40mail.gmail.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHaGr-tfPJUz4y2s9MWHNJHYUd5DS%2BgtmwrFYc%2BQm0Vfg%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6pkXqc8-a%3D0S5j6nzw7YuKgAnSgEz_w_Q2%2B4KTnfaZdyw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFoxvgzPMuaDwNtRm3DNjwLNuboKWFW-B-OZmoHq2czVP_ZExQ%40mail.gmail.com.

Re: JEP-13: timja youtube permissions for JCasc

[Tracy Miranda]

+1

On Fri, Jan 31, 2020 at 3:27 AM Mark Waite 
wrote:

> +1 from me
>
> On Fri, Jan 31, 2020 at 9:22 AM Tim Jacomb  wrote:
>
>> Hi
>>
>> As a sub-project leader for JCasc I'm requesting permission to upload
>> videos to the jenkinsci youtube channel for JCasC sub-project meetings
>>
>>
>> https://github.com/jenkinsci/jep/blob/master/jep/13/README.adoc#eligibility
>>
>> I have a signed ICLA:
>> https://github.com/jenkinsci/infra-cla/tree/master/collected/icla/timja
>> and my google account has 2fa on it
>>
>> Thanks
>> Tim
>>
>> --
>> 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/CAH-3BieuhqJAAcDMC%3Dz-OcvkG26z3exQERTpvw1uxZ_4MKfmAQ%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHaGr-tfPJUz4y2s9MWHNJHYUd5DS%2BgtmwrFYc%2BQm0Vfg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6pkXqc8-a%3D0S5j6nzw7YuKgAnSgEz_w_Q2%2B4KTnfaZdyw%40mail.gmail.com.

Re: PROPOSAL: Remove network discovery services

[Ivan Fernandez Calvo]

Swarm plugin has about 7000 installations, this is the potential Jenkins 
instances affected, I am agree to remove it from the core but I think that 
should be provided as a plugin, maybe the needed staff can be moved to the 
swarm plugin.

-- 
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/f02c1bff-41ef-4bce-bd9d-27b230d9fd68%40googlegroups.com.

Re: JEP-13: timja youtube permissions for JCasc

[Mark Waite]

+1 from me

On Fri, Jan 31, 2020 at 9:22 AM Tim Jacomb  wrote:

> Hi
>
> As a sub-project leader for JCasc I'm requesting permission to upload
> videos to the jenkinsci youtube channel for JCasC sub-project meetings
>
> https://github.com/jenkinsci/jep/blob/master/jep/13/README.adoc#eligibility
>
> I have a signed ICLA:
> https://github.com/jenkinsci/infra-cla/tree/master/collected/icla/timja
> and my google account has 2fa on it
>
> Thanks
> Tim
>
> --
> 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/CAH-3BieuhqJAAcDMC%3Dz-OcvkG26z3exQERTpvw1uxZ_4MKfmAQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHaGr-tfPJUz4y2s9MWHNJHYUd5DS%2BgtmwrFYc%2BQm0Vfg%40mail.gmail.com.

JEP-13: timja youtube permissions for JCasc

[Tim Jacomb]

Hi

As a sub-project leader for JCasc I'm requesting permission to upload
videos to the jenkinsci youtube channel for JCasC sub-project meetings

https://github.com/jenkinsci/jep/blob/master/jep/13/README.adoc#eligibility

I have a signed ICLA:
https://github.com/jenkinsci/infra-cla/tree/master/collected/icla/timja
and my google account has 2fa on it

Thanks
Tim

-- 
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/CAH-3BieuhqJAAcDMC%3Dz-OcvkG26z3exQERTpvw1uxZ_4MKfmAQ%40mail.gmail.com.