Plugins using removed Guava APIs

[Basil Crow]

I started looking into which plugins use classes or methods from Guava
11 that have been removed in Guava 30. There is plenty of low-hanging
fruit if anyone is interested in contributing by rewriting these
usages. The list below is far from exhaustive, but it's a start. If
you maintain one of these plugins, consider taking some proactive
steps to migrate away from these APIs.

com/google/common/base/Objects#firstNonNull
- blueocean-pipeline-api-impl
- blueocean-pipeline-scm-api
- ec2-fleet
- gearman-plugin
- github
- jclouds-jenkins
- jira

com/google/common/base/Objects#toStringHelper
- blueocean-rest-impl
- build-monitor-plugin
- cloudfoundry-bosh-cli
- docker-plugin
- extreme-feedback
- google-source-plugin
- gravatar
- repository
- splunk-devops-extend

com/google/common/base/Stopwatch#elapsedMillis
- build-monitor-plugin

com/google/common/base/Stopwatch#elapsedTime
- relution-publisher
- vsphere-cloud

com/google/common/collect/Ranges
- audit-trail
- elastest
- http_request
- logstash
- scm-httpclient

com/google/common/io/Files#newOutputStreamSupplier
- repository-connector

com/google/common/net/InternetDomainName#name
- scm-api

com/google/common/util/concurrent/MoreExecutors#sameThreadExecutor
- workflow-basic-steps

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

Re: Stapler IntelliJ Plugin JetBrains Marketplace listing

[Tim Van Holder]

Can I get added as well? Might give me a reason to dive into IntelliJ
platform stuff.
I use either IDEA or Rider on a daily basis, so was only a matter of time I
suppose.

On Wed, 5 May 2021 at 09:46, Oleg Nenashev  wrote:

> Good question. I added the board, because I do not know which kind of
> traffic we will get.
> Changing to Infra is reasonable.
>
>
> On Wednesday, May 5, 2021 at 9:44:30 AM UTC+2 timja...@gmail.com wrote:
>
>> I see the board is the email contact,
>> https://plugins.jetbrains.com/organizations/jenkins
>>
>> Is that an expected contact point? Would it be better to set the dev
>> mailing list or infra?
>>
>> On Wed, 5 May 2021 at 08:41, Oleg Nenashev  wrote:
>>
>>> Added Tim and Kohsuke to the org. Everyone is admin for now.
>>> We can figure out permissions later if needed
>>>
>>> On Wednesday, May 5, 2021 at 9:36:32 AM UTC+2 timja...@gmail.com wrote:
>>>
 > If you want to join the org, please share your JetBrains Marketplace
 account IDs

 my email is my ID as far as I can tell

 On Wed, 5 May 2021 at 07:58, Denys Digtiar  wrote:

> > Maybe it makes sense to rename the plugin to "Jenkins plugin",
> Stapler is not really used elsewhere. Having it as Jenkins plugin allows 
> to
> add more Jenkins-specific features,
> I actually had the same though. I even put it in writing :)
> https://github.com/stapler/idea-stapler-plugin/issues/43
>
> On Wednesday, 5 May 2021 at 16:51:12 UTC+10 Oleg Nenashev wrote:
>
>> I went ahead and created
>> https://plugins.jetbrains.com/organizations/jenkins . If you want to
>> join the org, please share your JetBrains Marketplace account IDs in this
>> thread.
>> And thanks to Denys for driving this topic!
>>
>> On Wednesday, May 5, 2021 at 8:44:19 AM UTC+2 Oleg Nenashev wrote:
>>
>>> +1000 as well
>>>
>>> I am not sure we want to just move the existing plugin though. Maybe
>>> it makes sense to rename the plugin to "Jenkins plugin", Stapler is not
>>> really used elsewhere. Having it as Jenkins plugin allows to add more
>>> Jenkins-specific features, e.g. better developer run mode or deeper
>>> integrations with Jenkins Test Harness, or various context help 
>>> dedicated
>>> to Jenkins development (e.g. REST API, permission check checks, custom
>>> static analysis rules, etc., etc.). I would also suggest moving it to 
>>> the
>>> jenkinsci GitHub organization so that we could manage it more 
>>> efficiently
>>> and attract contributors.
>>>
>>>
>>>
>>>
>>> On Wednesday, May 5, 2021 at 8:21:17 AM UTC+2 timja...@gmail.com
>>> wrote:
>>>
 +1000

 On Wed, 5 May 2021 at 02:48, Denys Digtiar 
 wrote:

>
> Posting here based on the discussion in
> @stapler/idea-stapler-plugin#44
> 
>
> Stapler plugin for IntelliJ IDEA is currently listed under KK's
> account.
> JetBrains added JetBrains Marketplace Organizations
> 
> which enables plugin listing/management by a group of people.
>
> Would it be possible to create a Jenkins organization?
> KK then will be able to transfer the plugin to be managed by the
> wider Jenkins community.
>
> As a follow-up, the release process can then be fully automated,
> see https://github.com/stapler/idea-stapler-plugin/issues/14
>
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e1aaf8ea-f767-4aa5-aac6-4695718ad596n%40googlegroups.com
> 
> .
>
 --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-de...@googlegroups.com.
>
 To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a36e20af-d65a-4363-93fe-17384e01c8c5n%40googlegroups.com
> 
> .
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop 

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Tim Jacomb]

What do other communities do for meetings notes? I think k8s is google docs.

On Thu, 6 May 2021 at 17:37, Basil Crow  wrote:

> On Thu, May 6, 2021 at 9:26 AM Daniel Beck  wrote:
> >
> > As an example, I remember a contributor summit (FOSDEM 2020?) at which a
> topic was discussed and nobody else was aware it was discussed a few years
> back because the notes were in some random Google doc long forgotten about
> and not easily recovered.
>
> As a former coworker of mine (a technical writer) used to say: "Google
> Docs: where information goes to die."
>
> --
> 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/CAFwNDjrkGQX6mZ58mHpU490WbPcFjWihNjeby4v7yU97O2iJEw%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/CAH-3Biey%3Dr-pisnyPF5%2BUX1MRysfR24Ty7AGW%2Bp32jMiFzuu5A%40mail.gmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Basil Crow]

On Thu, May 6, 2021 at 9:26 AM Daniel Beck  wrote:
>
> As an example, I remember a contributor summit (FOSDEM 2020?) at which a 
> topic was discussed and nobody else was aware it was discussed a few years 
> back because the notes were in some random Google doc long forgotten about 
> and not easily recovered.

As a former coworker of mine (a technical writer) used to say: "Google
Docs: where information goes to die."

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

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Daniel Beck]

On Thu, May 6, 2021 at 6:01 PM Daniel Beck  wrote:

> It would be for meeting notes
>

As an example, I remember a contributor summit (FOSDEM 2020?) at which a
topic was discussed and nobody else was aware it was discussed a few
years back because the notes were in some random Google doc long forgotten
about and not easily recovered.

Not to mention the giant mess such a document becomes once there are
multiple meeting tracks.

Project meeting, SIG meetings, contributor summit, other odds and ends –
that's what this would be for.


> perhaps project proposals for GSOC, etc.
>

To clarify, while ideas are being developed. At some point it probably
should be moved to the site proper. (I may not be involved enough in this
process though, so this may be a bad example.)

-- 
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/CAMo7PtLYO0t-1bbf-a3wzdY_paMbpsVTN%2BZ2N4zu49ACi6b_cQ%40mail.gmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Oleg Nenashev]

>
> Ideally, I would like to easily find old information especially when we
> organize events like Fosdem or to review past contributor summit notes.
>
any plans w.r.t. updating https://www.jenkins.io/events/fosdem/ then? :)


On Thu, May 6, 2021 at 6:08 PM Olblak  wrote:

> I am -1 for recovering Wiki as it was. -0 if we are talking about creating
> a new Wiki from scratch on Atlassian Cloud, just for Jenkins GitHub
> organization members. No Jenkins LDAP would be needed there if we chose
> such a way.
>
>
> -1 for Atlassian Cloud. To me, it's still not an option unless we ask
> contributors to create an Atlassian account.
>
> https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/
>
> I think that Google Docs are quite fine, and I am definitely responsible
> for dozens of Google Docs we have in the community.
>
>
> To me, they are throw away documentation. Ideally, I would like to easily
> find old information especially when we organize events like Fosdem or to
> review past contributor summit notes.
>
>
>
> On Thu, May 6, 2021, at 4:45 PM, Oleg Nenashev wrote:
>
> I am -1 for recovering Wiki as it was. -0 if we are talking about creating
> a new Wiki from scratch on Atlassian Cloud, just for Jenkins GitHub
> organization members. No Jenkins LDAP would be needed there if we chose
> such a way.
>
> IMHO Wiki can be largely replaced by Documentation-as-Code in
> repositories, hackmd, and, if needed, on GitHub Wiki pages.SIGs could move
> the moist of the contents there. Same for the Governance meeting, we could
> move to HackMd easily. Advanced forums like Discourse could also help to
> store particular pieces of content one would put on Wiki
>
> I think that Google Docs are quite fine, and I am definitely responsible
> for dozens of Google Docs we have in the community. Indeed it is nearly
> impossible to find something due to many different accounts being used.
> Maybe having a sponsored GSuite account or Switching to OwnCloud could be
> an option if we want to centralize the location of the documents.
>
>
>
>
>
> On Thu, May 6, 2021 at 3:57 PM Tim Jacomb  wrote:
>
> Please no, wiki's suck for quality documentation.
>
> Anyone can put whatever rubbish they want there.
>
> On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure <
> jenkins-in...@googlegroups.com> wrote:
>
>
> Hi Everybody,
>
> During the last Infrastructure meeting
> ,
> Daniel Beck came with an interesting question.
>
> Considering the proliferation of Google documents and other random tools
> to take notes,
> shouldn't we consider bringing back Confluence?
>
> While I am not convinced that a wiki is THE solution, I definitely share
> his frustration.
> I feel we did a major step backward in terms of knowledge management
> across the Jenkins project.
>
> Nowadays, the default behavior is to create a Google document to take
> notes during meetings or event organizations.
> This approach is very easy for synchronous collaboration but it also has
> bad side effects. It's difficult to find old documents unless you
> bookmarked them. And, documents lifecycle are affected by the "new" google
> storage policy or corporate google accounts.
>
> Historically, we used the wiki to take notes and write documentation.
> https://wiki.jenkins.io/display/JENKINS
> That central place was really convenient to share and find information
> across community initiatives.
>
> That being said, I didn't forget the reasons to move away from Confluence,
> and here are some of them:
>
> 1. Spammers, because of the nature of the Jenkins project we tend to
> attract a lot of spammers. Then *someone* has to do some clean-up.
> 2. Maintaining confluence is a major distraction that nobody wants to do.
> 3. Confluence in the current state is very slow mainly due to point 2 and
> due to unfinished infrastructure work.
>
> The two last elements could be solved by asking the Linux Foundation to
> maintain Confluence. The same way they do for Jira
> 
> Also, it's worth keeping in mind that Atlassian is deprecating their
> on-prem solution in 2024.
>
> Several weeks ago, I started an experiment on the infrastructure project
> to use hackmd.io to allow synchronous collaboration on meeting notes.
> During a meeting or a maintenance window, everybody can participate then
> at the end of the meeting someone pushes the notes to a git repository like
> https://github.com/jenkins-infra/documentation/#documentation
> To me it combines two approaches, it's as easy as a Google document to
> collect notes and then we can easily store them on a git repository
> directly in Markdown.
> Unfortunately, I am not convinced by the asynchronous collaboration
> workflow.
>
> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the
> poor video)
>
> As I said it's an experiment, the purpose is to 

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

['Olblak' via Jenkins Developers]

> I am -1 for recovering Wiki as it was. -0 if we are talking about creating a 
> new Wiki from scratch on Atlassian Cloud, just for Jenkins GitHub 
> organization members. No Jenkins LDAP would be needed there if we chose such 
> a way.

-1 for Atlassian Cloud. To me, it's still not an option unless we ask 
contributors to create an Atlassian account.
https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/

> I think that Google Docs are quite fine, and I am definitely responsible for 
> dozens of Google Docs we have in the community.

To me, they are throw away documentation. Ideally, I would like to easily find 
old information especially when we organize events like Fosdem or to review 
past contributor summit notes.



On Thu, May 6, 2021, at 4:45 PM, Oleg Nenashev wrote:
> I am -1 for recovering Wiki as it was. -0 if we are talking about creating a 
> new Wiki from scratch on Atlassian Cloud, just for Jenkins GitHub 
> organization members. No Jenkins LDAP would be needed there if we chose such 
> a way. 
> 
> IMHO Wiki can be largely replaced by Documentation-as-Code in repositories, 
> hackmd, and, if needed, on GitHub Wiki pages.SIGs could move the moist of the 
> contents there. Same for the Governance meeting, we could move to HackMd 
> easily. Advanced forums like Discourse could also help to store particular 
> pieces of content one would put on Wiki
> 
> I think that Google Docs are quite fine, and I am definitely responsible for 
> dozens of Google Docs we have in the community. Indeed it is nearly 
> impossible to find something due to many different accounts being used. Maybe 
> having a sponsored GSuite account or Switching to OwnCloud could be an option 
> if we want to centralize the location of the documents.
> 
> 
> 
> 
> 
> On Thu, May 6, 2021 at 3:57 PM Tim Jacomb  wrote:
>> Please no, wiki's suck for quality documentation.
>> 
>> Anyone can put whatever rubbish they want there.
>> 
>> On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure 
>>  wrote:
>>> __
>>> Hi Everybody, 
>>> 
>>> During the last Infrastructure meeting 
>>> ,
>>>  Daniel Beck came with an interesting question.
>>> 
>>> Considering the proliferation of Google documents and other random tools to 
>>> take notes,
>>> shouldn't we consider bringing back Confluence?
>>> 
>>> While I am not convinced that a wiki is THE solution, I definitely share 
>>> his frustration.
>>> I feel we did a major step backward in terms of knowledge management across 
>>> the Jenkins project.
>>>  
>>> Nowadays, the default behavior is to create a Google document to take notes 
>>> during meetings or event organizations.
>>> This approach is very easy for synchronous collaboration but it also has 
>>> bad side effects. It's difficult to find old documents unless you 
>>> bookmarked them. And, documents lifecycle are affected by the "new" google 
>>> storage policy or corporate google accounts.
>>> 
>>> Historically, we used the wiki to take notes and write documentation. 
>>> https://wiki.jenkins.io/display/JENKINS
>>> That central place was really convenient to share and find information 
>>> across community initiatives.
>>> 
>>> That being said, I didn't forget the reasons to move away from Confluence, 
>>> and here are some of them:
>>> 
>>> 1. Spammers, because of the nature of the Jenkins project we tend to 
>>> attract a lot of spammers. Then *someone* has to do some clean-up.
>>> 2. Maintaining confluence is a major distraction that nobody wants to do. 
>>> 3. Confluence in the current state is very slow mainly due to point 2 and 
>>> due to unfinished infrastructure work.
>>> 
>>> The two last elements could be solved by asking the Linux Foundation to 
>>> maintain Confluence. The same way they do for Jira 
>>> 
>>> Also, it's worth keeping in mind that Atlassian is deprecating their 
>>> on-prem solution in 2024.
>>> 
>>> Several weeks ago, I started an experiment on the infrastructure project to 
>>> use hackmd.io to allow synchronous collaboration on meeting notes.
>>> During a meeting or a maintenance window, everybody can participate then at 
>>> the end of the meeting someone pushes the notes to a git repository like 
>>> https://github.com/jenkins-infra/documentation/#documentation
>>> To me it combines two approaches, it's as easy as a Google document to 
>>> collect notes and then we can easily store them on a git repository 
>>> directly in Markdown.
>>> Unfortunately, I am not convinced by the asynchronous collaboration 
>>> workflow.
>>> 
>>> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the 
>>> poor video)
>>> 
>>> As I said it's an experiment, the purpose is to simplify synchronous 
>>> collaboration and then persist the content on a git repository that can 
>>> easily be browsed.
>>> 
>>> I would 

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Daniel Beck]

On Thu, May 6, 2021 at 3:57 PM Tim Jacomb  wrote:

> Please no, wiki's suck for quality documentation.
>

It would not be intended for "quality documentation". That belongs on the
site (plugins.j.io via GH readmes, or jenkins.io otherwise). It would be
for meeting notes, perhaps project proposals for GSOC, etc. -- content like
that. Frequently updated, often short lived content, that's only looked at
seldom in the future.

Hence my suggestion to start over with a clean slate, recovering none of
the old content. There's just too much in there that should not be in a
wiki.

-- 
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/CAMo7PtLpWTppdmJHX-pH7t3Rcyw3j22OoHNSc8urM3%2BWERxpmQ%40mail.gmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Liam Newman]

>
> Please no, wiki's suck for quality documentation.
>

+1000


On Thu, May 6, 2021 at 6:57 AM Tim Jacomb  wrote:

> Please no, wiki's suck for quality documentation.
>
> Anyone can put whatever rubbish they want there.
>
> On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure <
> jenkins-in...@googlegroups.com> wrote:
>
>> Hi Everybody,
>>
>> During the last Infrastructure meeting
>> ,
>> Daniel Beck came with an interesting question.
>>
>> Considering the proliferation of Google documents and other random tools
>> to take notes,
>> shouldn't we consider bringing back Confluence?
>>
>> While I am not convinced that a wiki is THE solution, I definitely share
>> his frustration.
>> I feel we did a major step backward in terms of knowledge management
>> across the Jenkins project.
>>
>> Nowadays, the default behavior is to create a Google document to take
>> notes during meetings or event organizations.
>> This approach is very easy for synchronous collaboration but it also has
>> bad side effects. It's difficult to find old documents unless you
>> bookmarked them. And, documents lifecycle are affected by the "new" google
>> storage policy or corporate google accounts.
>>
>> Historically, we used the wiki to take notes and write documentation.
>> https://wiki.jenkins.io/display/JENKINS
>> That central place was really convenient to share and find information
>> across community initiatives.
>>
>> That being said, I didn't forget the reasons to move away from
>> Confluence, and here are some of them:
>>
>> 1. Spammers, because of the nature of the Jenkins project we tend to
>> attract a lot of spammers. Then *someone* has to do some clean-up.
>> 2. Maintaining confluence is a major distraction that nobody wants to do.
>> 3. Confluence in the current state is very slow mainly due to point 2 and
>> due to unfinished infrastructure work.
>>
>> The two last elements could be solved by asking the Linux Foundation to
>> maintain Confluence. The same way they do for Jira
>> 
>> Also, it's worth keeping in mind that Atlassian is deprecating their
>> on-prem solution in 2024.
>>
>> Several weeks ago, I started an experiment on the infrastructure project
>> to use hackmd.io to allow synchronous collaboration on meeting notes.
>> During a meeting or a maintenance window, everybody can participate then
>> at the end of the meeting someone pushes the notes to a git repository like
>> https://github.com/jenkins-infra/documentation/#documentation
>> To me it combines two approaches, it's as easy as a Google document to
>> collect notes and then we can easily store them on a git repository
>> directly in Markdown.
>> Unfortunately, I am not convinced by the asynchronous collaboration
>> workflow.
>>
>> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the
>> poor video)
>>
>> As I said it's an experiment, the purpose is to simplify synchronous
>> collaboration and then persist the content on a git repository that can
>> easily be browsed.
>>
>> I would be curious to know your feeling about all of this and if you have
>> other suggestions.
>>
>> Cheers
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Infrastructure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkins-infra+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.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/CAH-3BidiAX87%2BDenOYkqw2ArtQCc6HRXpNZ-r4To5gh2vNC7aQ%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/CAA0qCNzn-0nbF%2BcR%2BaVv5AXLovk8xchMKT2-GBt6s4Z3WqaW2g%40mail.gmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Oleg Nenashev]

I am -1 for recovering Wiki as it was. -0 if we are talking about creating
a new Wiki from scratch on Atlassian Cloud, just for Jenkins GitHub
organization members. No Jenkins LDAP would be needed there if we chose
such a way.

IMHO Wiki can be largely replaced by Documentation-as-Code in repositories,
hackmd, and, if needed, on GitHub Wiki pages.SIGs could move the moist of
the contents there. Same for the Governance meeting, we could move to
HackMd easily. Advanced forums like Discourse could also help to store
particular pieces of content one would put on Wiki

I think that Google Docs are quite fine, and I am definitely responsible
for dozens of Google Docs we have in the community. Indeed it is nearly
impossible to find something due to many different accounts being used.
Maybe having a sponsored GSuite account or Switching to OwnCloud could be
an option if we want to centralize the location of the documents.





On Thu, May 6, 2021 at 3:57 PM Tim Jacomb  wrote:

> Please no, wiki's suck for quality documentation.
>
> Anyone can put whatever rubbish they want there.
>
> On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure <
> jenkins-in...@googlegroups.com> wrote:
>
>> Hi Everybody,
>>
>> During the last Infrastructure meeting
>> ,
>> Daniel Beck came with an interesting question.
>>
>> Considering the proliferation of Google documents and other random tools
>> to take notes,
>> shouldn't we consider bringing back Confluence?
>>
>> While I am not convinced that a wiki is THE solution, I definitely share
>> his frustration.
>> I feel we did a major step backward in terms of knowledge management
>> across the Jenkins project.
>>
>> Nowadays, the default behavior is to create a Google document to take
>> notes during meetings or event organizations.
>> This approach is very easy for synchronous collaboration but it also has
>> bad side effects. It's difficult to find old documents unless you
>> bookmarked them. And, documents lifecycle are affected by the "new" google
>> storage policy or corporate google accounts.
>>
>> Historically, we used the wiki to take notes and write documentation.
>> https://wiki.jenkins.io/display/JENKINS
>> That central place was really convenient to share and find information
>> across community initiatives.
>>
>> That being said, I didn't forget the reasons to move away from
>> Confluence, and here are some of them:
>>
>> 1. Spammers, because of the nature of the Jenkins project we tend to
>> attract a lot of spammers. Then *someone* has to do some clean-up.
>> 2. Maintaining confluence is a major distraction that nobody wants to do.
>> 3. Confluence in the current state is very slow mainly due to point 2 and
>> due to unfinished infrastructure work.
>>
>> The two last elements could be solved by asking the Linux Foundation to
>> maintain Confluence. The same way they do for Jira
>> 
>> Also, it's worth keeping in mind that Atlassian is deprecating their
>> on-prem solution in 2024.
>>
>> Several weeks ago, I started an experiment on the infrastructure project
>> to use hackmd.io to allow synchronous collaboration on meeting notes.
>> During a meeting or a maintenance window, everybody can participate then
>> at the end of the meeting someone pushes the notes to a git repository like
>> https://github.com/jenkins-infra/documentation/#documentation
>> To me it combines two approaches, it's as easy as a Google document to
>> collect notes and then we can easily store them on a git repository
>> directly in Markdown.
>> Unfortunately, I am not convinced by the asynchronous collaboration
>> workflow.
>>
>> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the
>> poor video)
>>
>> As I said it's an experiment, the purpose is to simplify synchronous
>> collaboration and then persist the content on a git repository that can
>> easily be browsed.
>>
>> I would be curious to know your feeling about all of this and if you have
>> other suggestions.
>>
>> Cheers
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Infrastructure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkins-infra+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Infrastructure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkins-infra+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> 

Re: JEPs & BDFL ~ KK

[Oleg Nenashev]

Hi all,

We have not reached the JEP topic at the yesterday's governance meeting. At 
the same time, I went ahead and tried to implement what seemed to be a 
consensus to me in this discussion: 
https://github.com/jenkinsci/jep/pull/359 . After some consideration I put 
3 roles in the JEP:

   - Champion
   - Advisor - optional, as discussed above
   - Reviewer - defaults to the Jenkins community and the standard 
   Governance process, unless the community delegates the review and the final 
   decision to another entity.
   
Note that we will need KK's approval for this changes as BDFL, but firstly 
I'd like to ensure we have a consensus in the proposal. I have also reached 
out to Kohsuke to check with him regarding the BDFL role and wjhether we 
should deprecate it, but for now I kept it as an active role withouut any 
responsibilities or priviliges.

Any feedback will be appreciated. 

Best regards,
Oleg Nenashev


On Wednesday, May 5, 2021 at 9:00:20 PM UTC+2 Oleg Nenashev wrote:

> I suggest landing the already agreed changes first. I see merits in some 
>  redesign, but I would not like to block other changes by that
>
> On Wed, May 5, 2021 at 8:53 PM Jesse Glick  wrote:
>
>> On Wed, May 5, 2021 at 2:44 PM Liam Newman  wrote:
>>
>>> Instead of having proposed JEPs sit as PRs until they meet the bar for 
>>> "Draft"
>>>
>>
>> It is a pretty low bar I think. You just have to finish writing what you 
>> plan to do.
>>  
>>
>>> This would allow people to more easily collaborate on getting JEPs to 
>>> Draft state.
>>>
>>
>> If there are truly multiple authors writing content, there are already 
>> plenty of ways for people to collaboratively draft documents. YAGNI?
>>
>> -- 
>>
> 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/hepntz6WZak/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> jenkinsci-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr20tELavC%2BSEb1b2sKSMMHthWWhgZXm3YC%3DuGMtcrCvWQ%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/85973d78-96e7-414e-9be0-0b79bbfd83adn%40googlegroups.com.

Re: New BOM version 807.v6d348e44c987 seems out of step with the versioning pattern

[Chris Kilding]

Great, thanks for confirming that.

Chris

On Thu, 6 May 2021, at 2:56 PM, Tim Jacomb wrote:
> Yes it's moved to CD releases https://www.jenkins.io/jep/229 
> 
> https://github.com/jenkinsci/bom/issues/510
> 
> On Thu, 6 May 2021 at 11:59, Chris Kilding  > wrote:
>> Hi all,
>> 
>> The new BOM version today is 807.v6d348e44c987. This seems quite out of step 
>> with the previous versioning pattern - 27, 28, 29 etc. Was this change 
>> intentional?
>> 
>> Chris
>> 
>> -- 
>> 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/ba3ba5dd-6275-4273-ab21-d1828abdd337%40www.fastmail.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/CAH-3BicPqMc6HWAqqGB55M0AKEyHTUBD4gOzDdO%3DzVt_Z7Wk%2BQ%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/231ce802-b1e1-4ef0-94c5-bf8be499038c%40www.fastmail.com.

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

[Tim Jacomb]

Please no, wiki's suck for quality documentation.

Anyone can put whatever rubbish they want there.

On Thu, 6 May 2021 at 14:41, 'Olblak' via Jenkins Infrastructure <
jenkins-in...@googlegroups.com> wrote:

> Hi Everybody,
>
> During the last Infrastructure meeting
> ,
> Daniel Beck came with an interesting question.
>
> Considering the proliferation of Google documents and other random tools
> to take notes,
> shouldn't we consider bringing back Confluence?
>
> While I am not convinced that a wiki is THE solution, I definitely share
> his frustration.
> I feel we did a major step backward in terms of knowledge management
> across the Jenkins project.
>
> Nowadays, the default behavior is to create a Google document to take
> notes during meetings or event organizations.
> This approach is very easy for synchronous collaboration but it also has
> bad side effects. It's difficult to find old documents unless you
> bookmarked them. And, documents lifecycle are affected by the "new" google
> storage policy or corporate google accounts.
>
> Historically, we used the wiki to take notes and write documentation.
> https://wiki.jenkins.io/display/JENKINS
> That central place was really convenient to share and find information
> across community initiatives.
>
> That being said, I didn't forget the reasons to move away from Confluence,
> and here are some of them:
>
> 1. Spammers, because of the nature of the Jenkins project we tend to
> attract a lot of spammers. Then *someone* has to do some clean-up.
> 2. Maintaining confluence is a major distraction that nobody wants to do.
> 3. Confluence in the current state is very slow mainly due to point 2 and
> due to unfinished infrastructure work.
>
> The two last elements could be solved by asking the Linux Foundation to
> maintain Confluence. The same way they do for Jira
> 
> Also, it's worth keeping in mind that Atlassian is deprecating their
> on-prem solution in 2024.
>
> Several weeks ago, I started an experiment on the infrastructure project
> to use hackmd.io to allow synchronous collaboration on meeting notes.
> During a meeting or a maintenance window, everybody can participate then
> at the end of the meeting someone pushes the notes to a git repository like
> https://github.com/jenkins-infra/documentation/#documentation
> To me it combines two approaches, it's as easy as a Google document to
> collect notes and then we can easily store them on a git repository
> directly in Markdown.
> Unfortunately, I am not convinced by the asynchronous collaboration
> workflow.
>
> There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the
> poor video)
>
> As I said it's an experiment, the purpose is to simplify synchronous
> collaboration and then persist the content on a git repository that can
> easily be browsed.
>
> I would be curious to know your feeling about all of this and if you have
> other suggestions.
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Infrastructure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkins-infra+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/jenkins-infra/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.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/CAH-3BidiAX87%2BDenOYkqw2ArtQCc6HRXpNZ-r4To5gh2vNC7aQ%40mail.gmail.com.

Re: New BOM version 807.v6d348e44c987 seems out of step with the versioning pattern

[Tim Jacomb]

Yes it's moved to CD releases https://www.jenkins.io/jep/229

https://github.com/jenkinsci/bom/issues/510

On Thu, 6 May 2021 at 11:59, Chris Kilding 
wrote:

> Hi all,
>
> The new BOM version today is 807.v6d348e44c987. This seems quite out of
> step with the previous versioning pattern - 27, 28, 29 etc. Was this change
> intentional?
>
> Chris
>
> --
> 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/ba3ba5dd-6275-4273-ab21-d1828abdd337%40www.fastmail.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/CAH-3BicPqMc6HWAqqGB55M0AKEyHTUBD4gOzDdO%3DzVt_Z7Wk%2BQ%40mail.gmail.com.

Should we bring back wiki.jenkins.io?

['Olblak' via Jenkins Developers]

Hi Everybody, 

During the last Infrastructure meeting 
,
 Daniel Beck came with an interesting question.

Considering the proliferation of Google documents and other random tools to 
take notes,
shouldn't we consider bringing back Confluence?

While I am not convinced that a wiki is THE solution, I definitely share his 
frustration.
I feel we did a major step backward in terms of knowledge management across the 
Jenkins project.
 
Nowadays, the default behavior is to create a Google document to take notes 
during meetings or event organizations.
This approach is very easy for synchronous collaboration but it also has bad 
side effects. It's difficult to find old documents unless you bookmarked them. 
And, documents lifecycle are affected by the "new" google storage policy or 
corporate google accounts.

Historically, we used the wiki to take notes and write documentation. 
https://wiki.jenkins.io/display/JENKINS
That central place was really convenient to share and find information across 
community initiatives.

That being said, I didn't forget the reasons to move away from Confluence, and 
here are some of them:

1. Spammers, because of the nature of the Jenkins project we tend to attract a 
lot of spammers. Then *someone* has to do some clean-up.
2. Maintaining confluence is a major distraction that nobody wants to do. 
3. Confluence in the current state is very slow mainly due to point 2 and due 
to unfinished infrastructure work.

The two last elements could be solved by asking the Linux Foundation to 
maintain Confluence. The same way they do for Jira 
Also, it's worth keeping in mind that Atlassian is deprecating their on-prem 
solution in 2024.

Several weeks ago, I started an experiment on the infrastructure project to use 
hackmd.io to allow synchronous collaboration on meeting notes.
During a meeting or a maintenance window, everybody can participate then at the 
end of the meeting someone pushes the notes to a git repository like 
https://github.com/jenkins-infra/documentation/#documentation
To me it combines two approaches, it's as easy as a Google document to collect 
notes and then we can easily store them on a git repository directly in 
Markdown.
Unfortunately, I am not convinced by the asynchronous collaboration workflow.

There is a demo here - https://youtu.be/1s2Y3aPXTOI?t=126 (Sorry for the poor 
video)

As I said it's an experiment, the purpose is to simplify synchronous 
collaboration and then persist the content on a git repository that can easily 
be browsed.

I would be curious to know your feeling about all of this and if you have other 
suggestions.

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/7fc740e9-3cfd-4daf-bb0d-44b7a8564930%40www.fastmail.com.

New BOM version 807.v6d348e44c987 seems out of step with the versioning pattern

[Chris Kilding]

Hi all,

The new BOM version today is 807.v6d348e44c987. This seems quite out of step 
with the previous versioning pattern - 27, 28, 29 etc. Was this change 
intentional?

Chris

-- 
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/ba3ba5dd-6275-4273-ab21-d1828abdd337%40www.fastmail.com.

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

[Oleg Nenashev]

Hi all,

We made decisions on a few terms at the yesterday's governance meeting:

   - Master node => "Built-in Node"
   - "master" label => "built-in" // We will use it unless we discover a 
   technical issue with the hyphen. Then we fallback to “builtin” 
   - “Master branch” in documentation and help => "default branch"
   - Agent-to-Master security => " Agent-to-Controller security "
   - "Jenkins master container " => "Jenkins controller container"
   - "Serialization whitelist" for JEP-200 => "serialization allowlist"

We also agreed that we will be using "allowlist" in our terminology, not 
the "permitlist" as it was suggested in a few occasions. We have not 
finalized decisions on other terms, including the "Jenkins master pod". I 
raised https://github.com/jenkinsci/kubernetes-operator/issues/561 in the 
Jenkins operator project to track the change on its side once we agree on 
the term.

If anyone is interested, I can create a global "terminology cleanup" 
project in the jenkinsci organization. It will allow tracking pull request 
better on the GitHub's side

Best regards,
Oleg Nenashev


On Wednesday, May 5, 2021 at 12:02:42 PM UTC+2 Daniel Beck wrote:

>
>
> > On 4. May 2021, at 16:59, Oleg Nenashev  wrote:
> > 
> > • Master node => "Built-in Node"
>
> To provide a bit of context for this one for those that don't remember 
> from last year :-)
>
> Before, there was no real distinction between "Jenkins master, the 
> process" (mostly) and "Jenkins master, the node". When I worked on the PR 
> in which I started cleaning up the terms, it became apparent a different 
> term could be useful.[1]
>
> A simple example: The built-in node can be offline while the controller is 
> otherwise running.
>
> In some code, the relation between master-specific and global node 
> properties also wasn't clear in some places because both were occasionally 
> called "master" (and only one set is inherited by agents).
>
> There's not a huge list of obvious examples because a lot of the things 
> that could matter are shared (process, file system, config file to an 
> extent) or irrelevant (node launcher).
>
> I still think it would be useful to distinguish in terms between the 
> controller and the built-in node, if only because 'controller' for the node 
> may create wrong associations (it controlling things, rather than "just" 
> being part of the controller process).
>
>
> However there are also limitations, which make a different term not an 
> obviously correct choice:
>
> - The built-in node is part of the controller process, it shares the 
> controller's file system and OS permissions. If the built-in node is doing 
> work, the controller has load. A lot of resources are shared, so "the 
> built-in node's configuration is stored in the config.xml file with most of 
> the controller configuration on the controller file system" etc.
> - People seem to confuse executors and nodes/agents fairly regularly, so 
> may well consider these to be the same thing because the differences are 
> way less relevant than compared to agents, leading to wrong documentation 
> and other advice, possibly confusing those aware of the terms. (It might 
> help that controller as a term is getting rather well established, and that 
> the node will get labels (both UI and environment var) referring to it by 
> its new name, but who knows.) 
>
>
> I encourage you to check out the PR with placeholder term to get a sense 
> for the differences and consider whether you think distinguishing the terms 
> is useful. As the PR is still a draft and uses an obvious placeholder term, 
> please skip doing an actual review for now.
>
> (Note that the behavior-changing code in my PR (related to migration) 
> would be needed anyway, regardless of the term we choose. It's more about 
> removing "master" than what the replacement term is.)
>
>
> 1: https://github.com/jenkinsci/jenkins/pull/5425
>
>

-- 
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/8507bd02-fbad-4844-aeb9-b1ee58753326n%40googlegroups.com.

Re: Jenkins Governance Meeting on May 05, 2021

[Oleg Nenashev]

 Thanks to all participants! And special thanks to Gavin for doing the 
meeting notes!

Recording of the Jenkins Governance meeting: https://youtu.be/hxn2LHWhaFQ . 
At this meeting we discussed the recent news: 2.277.4 Release, 
SheCodeAfrica contributhon completion, DevOps World CFP, and 5 years since 
the Jenkins 2.0 release. After that we confirmed Oleg Nenashev as the 
candidate for CDF TOC project representatives from Jenkins. Then we 
discussed removing Commons Digester from the Jenkins core and agreed on the 
next steps. We also voted on terminology and finalized some terms like 
"built-in" node. Then we confirmed the pilot project with the Linux 
Foundation and Snyk, focused on securing Jenkins delivery pipelines and 
adopting LFX Security 2.0. 

Participants: Ulli Hafner, Gavin Mogan, Ewelina Wilkosz, Daniel Beck, 
Baptiste Mathus, Mark Waite, Oleg Nenashev
Meeting notes: 
https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.69hapn3otwah
 

I will summarize the decisions in other threads

Best regards,
Oleg Nenashev

On Wednesday, May 5, 2021 at 10:05:55 AM UTC+2 Oleg Nenashev wrote:

> Added Commons Digester to the agenda. It looks like we need to agree in 
> the thread, e.g. whether JEP is needed
>
> On Tuesday, May 4, 2021 at 11:35:23 PM UTC+2 Baptiste Mathus wrote:
>
>> Yes, socializing the idea at this point I would say. And probably getting 
>> some potential feedback on the proposed action plan.
>>
>> As much as I would obviously love to move forward sooner than later, I 
>> think asking for a decision already would be a bit too early and 
>> disingenuous from me. 
>>
>>
>> Le mar. 4 mai 2021 à 23:16, Oleg Nenashev  a écrit :
>>
>>> Hu Baptiste. No objections from me w.r.t. adding it to the agenda. Do 
>>> you expect to get a deciaion there? Or is it just a way to socialiye the 
>>> proposal? Both options LGTM
>>>
>>> On Tue, May 4, 2021, 23:05 Baptiste Mathus  wrote:
>>>
 Hi Oleg, hi everyone, 

 I've just sent an email update in the other thread about 
 commons-digester:2.1. 
 If you think this would be worth raising this too during the governance 
 meeting, I can probably try and join this time (given 20:00 UTC+1 can work 
 for me, thanks Summer time :)).

 -- Baptiste

 Le mar. 4 mai 2021 à 19:16, Oleg Nenashev  a 
 écrit :

> Dear all,
>
> Tomorrow we will have the regular Jenkins Governance meeting. The 
> meeting will start at 7PM UTC, everyone is welcome to participate! 
> Calendar 
> link: here 
> 
>
> Current topics (full agenda and links 
> 
> ):
>
>- News: 2.277.4 Release, SheCodeAfrica summary, DevOps World
>- Confirming the CDF TOC project representative nomination for 
>Jenkins 
>- Terminology updates - finalizing the terms
>- Update on the Hosting team
>- Jenkins SDLC security - confirming the pilot project with LFX 
>Security and Snyk
>- Roadmap Updates Review
>- JEP Process updates (and BDFL?)
>- TBD: GitHub Issues for open governance projects/backlog
>- TBD: Plugin End-of-Life Policy
>
> If you want to add a topic, please suggest a topic in the Google Doc. 
> Note that we also have the Roadmap Review topic in the list. Everyone is 
> encouraged to submit their roadmap updates to the jenkins.io repo so 
> that we review them tomorrow: 
> https://github.com/jenkins-infra/jenkins.io/labels/roadmap . 
>
> #MayThe4BeWithYou,
> Oleg Nenashev
>
> -- 
> 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-de...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/3eb70f0b-389a-46c5-ba53-63d5e36357edn%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/YzRC7tvi8tA/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to 
 jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit