Re: Terminology Updates

[Richard Bywater]

> I personally think without the slave context, master is pretty accurate

That's a good point. I did a quick search and noticed that Apache Mesos
renamed to agents a few years back but left the main controller as being a
"master" so there is some precedent there.

Richard.

On Sat, 13 Jun 2020 at 05:05, 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Control plane works but is a mouthfull. Controller works, but as others
> pointed out, could easily be confused in the k8s world.
>
> the other two (Host and Server) are way too generic to convey meaning if
> you don't know the system.
>
> You could go silly like POTUJ (President of the United Jenkins) or JOTUJ
> (Jenkins of the United Jenkins).
> Jenkins Brain
> Jenkins President
> Jenkins CEO
> Jenkins Manager
> Jenkins Foreman
> Jenkins Governor
> Jenkins Super / Super Jenkins
> Jenkins Taskmaster
> Jenkins Boss
> Jenkins Leader
> Jenkins Overlord
>
> A lot came from
> https://www.wordhippo.com/what-is/another-word-for/controller.html
>
> I personally think without the slave context, master is pretty accurate.
> To be absolutely honest, if it has more syllables than the current, people
> are super likely to stick with the existing wording (Slave-1 vs Agent-2)
> cause its easier to say/remember.
>
> Gavin
>
>
> On Fri, Jun 12, 2020 at 9:13 AM Jeff Thompson 
> wrote:
>
>> My favorite is "Jenkins server" or something like that. There are already
>> existing usages and it's reasonably explanatory. Something with "manager"
>> could also work, but I don't find the term as clean and clear.
>>
>> Outside of bias issues, one of the problems with whitelist and blacklist
>> is that the terms don't really say what they do. Sometimes the
>> interpretation depends on which way you're looking at it. Somewhat similar
>> to whether a class hierarchy goes up or down.
>>
>> "AllowList" and "DenyList" are good matching pairs that convey more
>> semantics about what they do.
>>
>> In other discussions we have noted that not all usages of
>> whitelist/blacklist fall into the same behavioral meaning. Sometimes we
>> will need to use different terminology to better convey the meaning.
>>
>> Jeff
>> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>>
>> I am +1 for changing the terminology, and I encourage Jenkins
>> contributors to participate in this effort. It is not something we could
>> change in a minute, but we could do a gradual cleanup and improve the
>> overall documentation while doing so.
>>
>> I am -1 w.r.t "host" due to the following reasons:
>>
>>- Host term is very generic, it has thousands of usages in Jenkins
>>https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing
>>this term will require a careful cleanup to avoid confusion in user
>>documentation and the codebase
>>- "agent host" is often used to describe target hosts for outbound
>>agents
>>
>> My suggestion would be to consider a *"Jenkins server"* term. You can
>> see that such a term is already used in our codebase
>> ,
>> website
>> and
>> on 3rd party resources
>> 
>> .
>>
>> Best regards,
>> Oleg
>>
>> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>>>
>>> It is a suggestion for consideration if you would like.
>>>
>>> On Jun 11, 2020, at 9:35 PM, Richard Bywater  wrote:
>>>
>>> 
>>> Good point. I actually wonder if Manager is a reasonable replacement?
>>>
>>> On Fri, 12 Jun 2020 at 16:04, Marky Jackson  wrote:
>>>
 The concern with controller may be a conflict with Kubernetes on
 Jenkins given the same name. This was originally my suggestion but than I
 remembered I was also part of renaming in that community.

 > On Jun 11, 2020, at 9:02 PM, Richard Bywater 
 wrote:
 >

>>> --
>>> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%40mail.gmail.com
>>> 
>>> .
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 

Re: Proposal: Jenkins Code of Conduct update (Contributor Covenant 1.3 -> 1.4)

[Jeff Thompson]

I couldn't find any good information on the differences between the 
versions so I cloned the repo and diffed between the versions. It works 
pretty well, though it's a little difficult to understand the 
differences at times.


I find that each new version is an improvement over the previous. The 
1.4 is better than the 1.3. I find that the 2.0 version is best.


The 2.0 version changes to using "community" consistently. Formerly it 
used both "project" and "community".


This line is added to expected behavior in 2.0 and I really like its 
inclusion: "Accepting responsibility and apologizing to those affected 
by our mistakes, and learning from the experience."


I like this addition in 2.0: "and will communicate reasons for 
moderation decisions when appropriate." As one who has moderated and 
been moderated in a variety of forums, communicating reasons is valuable.


This part is very nicely improved in 2.0: "All complaints will be 
reviewed and investigated promptly and fairly. All community leaders are 
obligated to respect the privacy and security of the reporter of any 
incident." This can be extremely important when an incident occurs.


Version 2.0 adds enforcement guidelines, which are important to spell 
out if there are ever any misbehaviors. Over the past few years, I've 
read many cases of communities, virtual and physical, who have 
encountered misbehaving individuals. Having a code of conduct has turned 
out to be very valuable for them. Having some part of it include 
enforcement gives the leaders and members something to refer to.


I believe the 2.0 version contains the best and latest understandings on 
these issues and that we would be best to adopt it.


Jeff

On 6/12/20 3:31 PM, Tracy Miranda wrote:

+1 for proposal (1.4 version)

Tracy

On Fri, Jun 12, 2020 at 5:06 PM Oleg Nenashev > wrote:


Dear all,

As a follow-up to the previous Governance meeting, I would like to
propose updating the Jenkins Code of Conduct
 (CoC). Currently it is
based on Contributor Covenant 1.3

which was officially adopted on Jan 06, 2016. Contributor Covenant
is widely used in open-source projects, and this was the most
recent version at that time. Now there are versions 1.4

and 2.0

of Contributor Covenant.
*
*
*Why update? * New versions of Contributor Covenant  extend our
version significantly, e.g. pledge and standards,
unacceptable behavior, representing the project and social media
matters, etc. These changes are pretty important IMHO. Also, we
have recently started a process of aligning the Jenkins project
with graduated project criteria defined by the Continuous Delivery
Foundation (see the proposal from Tracy Miranda here
).
One of the checklist items is adopting the CDF's Code of Conduct

which is based on Contributor Covenant 1.4.

*Background.*  At the last Governance Meeting on Jun 03 we had a
sync-up with Dan Lorenc who is the current CDF Technical Oversight
Committee chair. Links are here: recording
, meeting notes

.
Some clarification we have got:

  * CDF does not require us to adopt the CDF Code of Conduct as
long as the Jenkins project has one and as long as they are
aligned. We interpret it as using a similar or compatible
version of Contributor Covenant.
  * CDF is fine with a 2-stage escalation process. We can keep the
Jenkins Governance Board as a first stage as it is currently
documented
. CDF can
act as a second level of escalation and as an entity for
mitigating cross-project Code of Conduct escalations should it
happen
  * Right now there is no confirmed plan to update CDF's Code of
Conduct to version 2.0

There is also a consensus that we would like to update the code of
conduct, especially taking the terminology update discussions

which are a sensitive topic to many Jenkins contributors. We have
3 options:

  * Update to Contributor Covenant 1.4

  * Update to Contributor Covenant 2.0
.
Note that there is still 

Re: Proposal: Jenkins Code of Conduct update (Contributor Covenant 1.3 -> 1.4)

[Tracy Miranda]

+1 for proposal (1.4 version)

Tracy

On Fri, Jun 12, 2020 at 5:06 PM Oleg Nenashev 
wrote:

> Dear all,
>
> As a follow-up to the previous Governance meeting, I would like to propose
> updating the Jenkins Code of Conduct
>  (CoC). Currently it is based on 
> Contributor
> Covenant 1.3
> 
> which was officially adopted on Jan 06, 2016. Contributor Covenant is
> widely used in open-source projects, and this was the most recent version
> at that time. Now there are versions 1.4
>  and
> 2.0 
> of Contributor Covenant.
>
> * Why update? * New versions of Contributor Covenant  extend our version
> significantly, e.g. pledge and standards, unacceptable behavior,
> representing the project and social media matters, etc. These changes are
> pretty important IMHO. Also, we have recently started a process of aligning
> the Jenkins project with graduated project criteria defined by the
> Continuous Delivery Foundation (see the proposal from Tracy Miranda here
> ). One
> of the checklist items is adopting the CDF's Code of Conduct
> 
> which is based on Contributor Covenant 1.4.
>
> *Background.*  At the last Governance Meeting on Jun 03 we had a sync-up
> with Dan Lorenc who is the current CDF Technical Oversight Committee chair.
> Links are here: recording , meeting
> notes
> .
> Some clarification we have got:
>
>- CDF does not require us to adopt the CDF Code of Conduct as long as
>the Jenkins project has one and as long as they are aligned. We interpret
>it as using a similar or compatible version of Contributor Covenant.
>- CDF is fine with a 2-stage escalation process. We can keep the
>Jenkins Governance Board as a first stage as it is currently documented
>. CDF can act as a
>second level of escalation and as an entity for mitigating cross-project
>Code of Conduct escalations should it happen
>- Right now there is no confirmed plan to update CDF's Code of Conduct
>to version 2.0
>
> There is also a consensus that we would like to update the code of
> conduct, especially taking the terminology update discussions
>  which
> are a sensitive topic to many Jenkins contributors. We have 3 options:
>
>- Update to Contributor Covenant 1.4
>
>- Update to Contributor Covenant 2.0
>.
>Note that there is still no changelog for the version 2.0, some "breaking
>changes" are mentioned here
>.
>There is also no Git tags, so we cannot really ensure that the version 2.0
>is fixed
>- Keep it as is, Contributor Covenant 1.3
>
>
> *Proposal*: I suggest updating Jenkins Code of Conduct to version 1.4.
> Taking the lack of changelog and Git tags for the version 2.0, I am not
> sure it is worth going with this version for now. The breaking changes also
> seem to be pretty important, and I am not sure we want to deviate from the
> CDF's CoC version and explore the legal differences. We can update CoC
> again when and if CDF goes to a higher version of Contributor Covenant.
>
> I would appreciate any feedback, and I suggest to vote on the update at
> the next Governance meeting
>  on June 17th.
>
> Thanks for your time,
> 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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCHDM6jEZJ%3D6t%3DWN%2BRJLiGFw%2BFTvxsjGzuKKoWHZWyW6A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: Plugin adoption request: NUnit

[Oleg Nenashev]

+1 from me, it would be great to have a new maintainer in this plugin.
Thanks a lot for stepping up!

I have also pinged the code reviewers team, let's see whether we could get 
some reviews.

BR, Oleg

On Friday, June 12, 2020 at 5:07:06 PM UTC+2, Shin-ichi Morita wrote:
>
> Hi Team,
>
> I would like to adopt NUnit plugin and request commit access.
>
> My current interest is fixing JENKINS-50162. I submitted this pull request 
> about 20 days ago without noticing it is marked for adoption.
>
> * Link to a plugin you want to adopt: 
> https://github.com/jenkinsci/nunit-plugin
> * Link(s) to pull requests you want to deliver: 
> https://github.com/jenkinsci/nunit-plugin/pull/23
> * Your GitHub username/id: s-morita-being
> * Your Jenkins infrastructure account id: smorita
>
> Thank you in advance,
>
> Shin-ichi Morita
>
>
>

-- 
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/4ca0f8f6-77dd-4c22-b93b-180c20b3afb7o%40googlegroups.com.

Re: Proposal: Jenkins Code of Conduct update (Contributor Covenant 1.3 -> 1.4)

[Marky Jackson]

I am a +1 to the proposal and feel this will benefit the community greatly.

> On Jun 12, 2020, at 2:05 PM, Oleg Nenashev  wrote:
> 
> Dear all,
> 
> As a follow-up to the previous Governance meeting, I would like to propose 
> updating the Jenkins Code of Conduct  
> (CoC). Currently it is based on Contributor Covenant 1.3 
>  which 
> was officially adopted on Jan 06, 2016. Contributor Covenant is widely used 
> in open-source projects, and this was the most recent version at that time. 
> Now there are versions 1.4 
>  and 2.0 
>  of 
> Contributor Covenant.
> 
> Why update?  New versions of Contributor Covenant  extend our version 
> significantly, e.g. pledge and standards, unacceptable behavior, representing 
> the project and social media matters, etc. These changes are pretty important 
> IMHO. Also, we have recently started a process of aligning the Jenkins 
> project with graduated project criteria defined by the Continuous Delivery 
> Foundation (see the proposal from Tracy Miranda here 
> ). One of 
> the checklist items is adopting the CDF's Code of Conduct 
>  which is 
> based on Contributor Covenant 1.4.
> 
> Background.  At the last Governance Meeting on Jun 03 we had a sync-up with 
> Dan Lorenc who is the current CDF Technical Oversight Committee chair. Links 
> are here: recording , meeting notes 
> .
>  Some clarification we have got:
> CDF does not require us to adopt the CDF Code of Conduct as long as the 
> Jenkins project has one and as long as they are aligned. We interpret it as 
> using a similar or compatible version of Contributor Covenant.
> CDF is fine with a 2-stage escalation process. We can keep the Jenkins 
> Governance Board as a first stage as it is currently documented 
> . CDF can act as a second 
> level of escalation and as an entity for mitigating cross-project Code of 
> Conduct escalations should it happen
> Right now there is no confirmed plan to update CDF's Code of Conduct to 
> version 2.0
> There is also a consensus that we would like to update the code of conduct, 
> especially taking the terminology update discussions 
>  which are 
> a sensitive topic to many Jenkins contributors. We have 3 options:
> Update to Contributor Covenant 1.4 
> 
> Update to Contributor Covenant 2.0 
> . Note 
> that there is still no changelog for the version 2.0, some "breaking changes" 
> are mentioned here 
> . 
> There is also no Git tags, so we cannot really ensure that the version 2.0 is 
> fixed
> Keep it as is, Contributor Covenant 1.3 
> 
> Proposal: I suggest updating Jenkins Code of Conduct to version 1.4. Taking 
> the lack of changelog and Git tags for the version 2.0, I am not sure it is 
> worth going with this version for now. The breaking changes also seem to be 
> pretty important, and I am not sure we want to deviate from the CDF's CoC 
> version and explore the legal differences. We can update CoC again when and 
> if CDF goes to a higher version of Contributor Covenant.
> 
> I would appreciate any feedback, and I suggest to vote on the update at the 
> next Governance meeting  
> on June 17th.
> 
> Thanks for your time,
> 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-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCHDM6jEZJ%3D6t%3DWN%2BRJLiGFw%2BFTvxsjGzuKKoWHZWyW6A%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 

Proposal: Jenkins Code of Conduct update (Contributor Covenant 1.3 -> 1.4)

[Oleg Nenashev]

Dear all,

As a follow-up to the previous Governance meeting, I would like to propose
updating the Jenkins Code of Conduct
 (CoC). Currently it is based
on Contributor
Covenant 1.3
 which
was officially adopted on Jan 06, 2016. Contributor Covenant is widely used
in open-source projects, and this was the most recent version at that time.
Now there are versions 1.4
 and 2.0
 of
Contributor Covenant.

* Why update? * New versions of Contributor Covenant  extend our version
significantly, e.g. pledge and standards, unacceptable behavior,
representing the project and social media matters, etc. These changes are
pretty important IMHO. Also, we have recently started a process of aligning
the Jenkins project with graduated project criteria defined by the
Continuous Delivery Foundation (see the proposal from Tracy Miranda here
). One
of the checklist items is adopting the CDF's Code of Conduct
 which
is based on Contributor Covenant 1.4.

*Background.*  At the last Governance Meeting on Jun 03 we had a sync-up
with Dan Lorenc who is the current CDF Technical Oversight Committee chair.
Links are here: recording , meeting
notes
.
Some clarification we have got:

   - CDF does not require us to adopt the CDF Code of Conduct as long as
   the Jenkins project has one and as long as they are aligned. We interpret
   it as using a similar or compatible version of Contributor Covenant.
   - CDF is fine with a 2-stage escalation process. We can keep the Jenkins
   Governance Board as a first stage as it is currently documented
   . CDF can act as a
   second level of escalation and as an entity for mitigating cross-project
   Code of Conduct escalations should it happen
   - Right now there is no confirmed plan to update CDF's Code of Conduct
   to version 2.0

There is also a consensus that we would like to update the code of conduct,
especially taking the terminology update discussions
 which
are a sensitive topic to many Jenkins contributors. We have 3 options:

   - Update to Contributor Covenant 1.4
   
   - Update to Contributor Covenant 2.0
   .
   Note that there is still no changelog for the version 2.0, some "breaking
   changes" are mentioned here
   .
   There is also no Git tags, so we cannot really ensure that the version 2.0
   is fixed
   - Keep it as is, Contributor Covenant 1.3
   

*Proposal*: I suggest updating Jenkins Code of Conduct to version 1.4.
Taking the lack of changelog and Git tags for the version 2.0, I am not
sure it is worth going with this version for now. The breaking changes also
seem to be pretty important, and I am not sure we want to deviate from the
CDF's CoC version and explore the legal differences. We can update CoC
again when and if CDF goes to a higher version of Contributor Covenant.

I would appreciate any feedback, and I suggest to vote on the update at the
next Governance meeting 
on June 17th.

Thanks for your time,
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCHDM6jEZJ%3D6t%3DWN%2BRJLiGFw%2BFTvxsjGzuKKoWHZWyW6A%40mail.gmail.com.

Re: Terminology Updates

[Jeff]

My vote:

   - Master -> Controller (Host and Server are too broad, and Control Plane
   is to verbose)
   - Whitelist/Blacklist -> Allowlist/Blocklist


On Thu, Jun 11, 2020 at 8:34 PM Slide  wrote:

> Hi Everyone,
>
>
>
> Back in the Jenkins 2.0 days, it was decided (rightfully so) to deprecate
> the term "slave" as it was used in the Jenkins project. There has been some
> significant progress made on this effort by many contributors with some
> remaining effort needing to be done (see the JENKINS-42816
>  EPIC). The agent
> terminology cleanup is recognized as a major initiative in the project, and
> it is listed on the Jenkins Public Roadmap Draft
> . We have some additional terminology
> that we would like to look at deprecating and replacing within the Jenkins
> project.
>
>
>
> The following terminology are items that we would like to replace with
> possible options. We would like this discussion to be civil, these words
> have powerful negative meanings for many people and we want to make sure,
> as a project, that we are using terms which are not negative. Please reply
> with opinions on the possible replacements that the Advocacy and Outreach
> SIG came up with, or others if you have additional ideas.
>
>
>
>-
>
>Master ->
>-
>
>   Host
>   -
>
>   Server
>   -
>
>   Control Plane
>   -
>
>Whitelist/Blacklist ->
>-
>
>   Allowlist/Denylist
>   -
>
>   Allowlist/Blocklist
>
>
>
> If there are other terms that you have seen in the Jenkins project that
> may need to be deprecated and replaced, please contact the Jenkins
> Governance Board members (jenkinsci-bo...@googlegroups.com) with your
> concerns.
>
>
>
> Regards,
>
>
>
> Alex Earl
>
> Jenkins Governance Board Member
>
>
> --
> 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/CAPiUgVe14X%2B8u8Vy7EGW30GW-i96rxPSMZm7-qMdzM6VcPtcSg%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/CADVhPTrcaWUR7EFU%3DRQge0y3UhVF%3DEE96W8X-xrRHQ_btKZNeA%40mail.gmail.com.

Re: ANN: Jenkins release artifacts uploads blockage on June 09, and a temporary downloads issue

[Liam Newman]

I have two releases that I consider high-priority: github-branch-source and 
github-api .

Users have been able to rollback to the previous release to unblock 
themselves, but people who cannot rollback (new installations) remain 
blocked.  




On Friday, June 12, 2020 at 10:05:33 AM UTC-7, Oleg Nenashev wrote:
>
> Dear all,
>
> June 12 update: 
>
>- We continue to work on the accounts migration and will share the 
>next update on Monday
>- Jenkins releases are still blocked. If there are any emergency 
>releases you need to perform, please reply in this thread.
>
> Best regards,
> Oleg Nenashev
>
> On Friday, June 12, 2020 at 6:00:32 PM UTC+2, Oleg Nenashev wrote:
>>
>> Hi Dave,
>>
>> This is an email from the *Step 2. We’ll reset every user password from 
>> the LDAP database*. This one includes a temporary password, and we 
>> expect users to change it after they login into the system.
>>
>> For those who wonder: Yes, the temporary password is sent in plain text 
>> as mentioned above. This is how our current password reset system is 
>> designed. As other projects, we have a decent amount of technical debt in 
>> our infrastructure which we gradually resolve. I have already added 
>> changing the account password reset flow to the outage retrospective list, 
>> an we will be reviewing what to do there after the outage is fully 
>> resolved. Apart from fixing it, migrating to a 3rd-party identity service 
>> is on the table for me (Linux Foundation or GitHub).  If anyone is 
>> interested to participate and to improve the project, the Jenkins 
>> infrastructure team  is 
>> always looking for more contributors!
>>
>> If anyone has concerns about such method and wants to use alternate 
>> channels for encrypted password transfer, please send us a message through 
>> the Jenkins Infrastructure mailing list from your email registered in 
>> Jenkins. In this email please provide your public GPG key so that we can 
>> reset a password again in a secure way.
>>
>> Best regards,
>> Oleg
>>
>> On Friday, June 12, 2020 at 5:07:27 PM UTC+2, Dave Pedu wrote:
>>>
>>> Hello,
>>>
>>> I have received an email linking to this thread. However, it contains a 
>>> plaintext password for my account, despite this:
>>>
>>> > There will be no temporary password in these emails, but there will 
>>> be information pointing to this thread.
>>>
>>> Is this email legitimate or am I being phished? Screenshot attached.
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Thursday, June 11, 2020 at 3:07:01 AM UTC-7, Olblak wrote:

 Dear all,

 We are ready to proceed with restoration of the Jenkins account 
 database. Today we are going to restore user LDAP accounts that were 
 created since the First of February 2020 based on the data from Jenkins 
 Jira and the repository Permission Manager metadata data. We will also 
 reset passwords for all users registered in the database.

 Step 1. All users who lost their account will receive an email saying 
 that their accounts were re-created. There will be no temporary password 
 in 
 these emails, but there will be information pointing to this thread.

 Step 2. We’ll reset every user password from the LDAP database, it is 
 more than 100 000 users. Once done, you’ll receive an email telling you 
 that your password was reset with a reason containing a link to this mail 
 thread.

 Step 3. We will delete accounts of users who requested such deletion 
 between February and June 2020. These users were restored from the backup, 
 so we have to delete them again.The list of users is based on Jira tickets 
 and private messages to the Jenkins Infra officer. If for some reason you 
 notice that your account still exists, feel free to raise a ticket in 
 Jenkins 
 Jira  (project=INFRA, component=account
 ).

 Please do not hesitate to contact us using the #jenkins-infra channel 
 on Freenode IRC or the Jenkins Infrastructure mailing list if you have any 
 questions or suggestions. If you see a security issue related to the 
 accounts, please follow the vulnerability reporting guidelines 
 .

 Best regards,

 Olivier Vernin && Jenkins Infrastructure Team


 On Tuesday, 9 June 2020 17:00:25 UTC+2, Oleg Nenashev wrote:
>
> Dear all,
>
> As you may have noticed, the release artifact uploads are currently 
> blocked in the Jenkins Artifactory instances (
> https://repo.jenkins-ci.org/). We are doing a security investigation 
> due to a partial user database loss on June 02. Today we blocked releases 
> to the Jenkins artifactory, and there also was a temporary outage of the 
> Artifactory downloads which was a collateral damage of the temporary 
> permissions. You 

Re: Terminology Updates

[Slide]

Jenkins Server makes sense to me as well. I'll add as a topic for the next
Governance meeting. Please also make sure and weigh in on
AllowList/DenyList and it's other derivatives.

On Fri, Jun 12, 2020, 10:43 Marky Jackson  wrote:

> I like Jenkins Server too
>
> > On Jun 12, 2020, at 10:41 AM, Matt Sicker  wrote:
> >
> > I also like Jenkins Server as a simple name.
> >
> > Other ideas: JenkinsD (like SystemD or any daemon), Jenkins Principal
> > (matches the principal/agent paradigm of agents executing code on
> > behalf of the principal).
> >
> > On Fri, Jun 12, 2020 at 12:37 PM Vlad Silverman 
> wrote:
> >>
> >> I agree, “Jenkins Server” reflects primary functionality and definitely
> makes sense.
> >>
> >> Thx, Vlad
> >>
> >> On Jun 12, 2020, at 10:21 AM, Mark Waite 
> wrote:
> >>
> >> My favorite is Jenkins server.  I'll use whatever term is ultimately
> selected, but "Jenkins server" is easier for me than "Control Plane".
> >>
> >> On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson 
> wrote:
> >>>
> >>> My favorite is "Jenkins server" or something like that. There are
> already existing usages and it's reasonably explanatory. Something with
> "manager" could also work, but I don't find the term as clean and clear.
> >>>
> >>> Outside of bias issues, one of the problems with whitelist and
> blacklist is that the terms don't really say what they do. Sometimes the
> interpretation depends on which way you're looking at it. Somewhat similar
> to whether a class hierarchy goes up or down.
> >>>
> >>> "AllowList" and "DenyList" are good matching pairs that convey more
> semantics about what they do.
> >>>
> >>> In other discussions we have noted that not all usages of
> whitelist/blacklist fall into the same behavioral meaning. Sometimes we
> will need to use different terminology to better convey the meaning.
> >>>
> >>> Jeff
> >>>
> >>> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
> >>>
> >>> I am +1 for changing the terminology, and I encourage Jenkins
> contributors to participate in this effort. It is not something we could
> change in a minute, but we could do a gradual cleanup and improve the
> overall documentation while doing so.
> >>>
> >>> I am -1 w.r.t "host" due to the following reasons:
> >>>
> >>> Host term is very generic, it has thousands of usages in Jenkins
> https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing this
> term will require a careful cleanup to avoid confusion in user
> documentation and the codebase
> >>> "agent host" is often used to describe target hosts for outbound agents
> >>>
> >>> My suggestion would be to consider a "Jenkins server" term. You can
> see that such a term is already used in our codebase, website and on 3rd
> party resources.
> >>>
> >>> Best regards,
> >>> Oleg
> >>>
> >>> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
> 
>  It is a suggestion for consideration if you would like.
> 
>  On Jun 11, 2020, at 9:35 PM, Richard Bywater 
> wrote:
> 
>  
>  Good point. I actually wonder if Manager is a reasonable replacement?
> 
>  On Fri, 12 Jun 2020 at 16:04, Marky Jackson 
> wrote:
> >
> > The concern with controller may be a conflict with Kubernetes on
> Jenkins given the same name. This was originally my suggestion but than I
> remembered I was also part of renaming in that community.
> >
> >> On Jun 11, 2020, at 9:02 PM, Richard Bywater 
> wrote:
> >>
> 
>  --
>  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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com
> .
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> >>> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.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 

Re: Terminology Updates

[Marky Jackson]

I like Jenkins Server too

> On Jun 12, 2020, at 10:41 AM, Matt Sicker  wrote:
> 
> I also like Jenkins Server as a simple name.
> 
> Other ideas: JenkinsD (like SystemD or any daemon), Jenkins Principal
> (matches the principal/agent paradigm of agents executing code on
> behalf of the principal).
> 
> On Fri, Jun 12, 2020 at 12:37 PM Vlad Silverman  wrote:
>> 
>> I agree, “Jenkins Server” reflects primary functionality and definitely 
>> makes sense.
>> 
>> Thx, Vlad
>> 
>> On Jun 12, 2020, at 10:21 AM, Mark Waite  wrote:
>> 
>> My favorite is Jenkins server.  I'll use whatever term is ultimately 
>> selected, but "Jenkins server" is easier for me than "Control Plane".
>> 
>> On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson  
>> wrote:
>>> 
>>> My favorite is "Jenkins server" or something like that. There are already 
>>> existing usages and it's reasonably explanatory. Something with "manager" 
>>> could also work, but I don't find the term as clean and clear.
>>> 
>>> Outside of bias issues, one of the problems with whitelist and blacklist is 
>>> that the terms don't really say what they do. Sometimes the interpretation 
>>> depends on which way you're looking at it. Somewhat similar to whether a 
>>> class hierarchy goes up or down.
>>> 
>>> "AllowList" and "DenyList" are good matching pairs that convey more 
>>> semantics about what they do.
>>> 
>>> In other discussions we have noted that not all usages of 
>>> whitelist/blacklist fall into the same behavioral meaning. Sometimes we 
>>> will need to use different terminology to better convey the meaning.
>>> 
>>> Jeff
>>> 
>>> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>>> 
>>> I am +1 for changing the terminology, and I encourage Jenkins contributors 
>>> to participate in this effort. It is not something we could change in a 
>>> minute, but we could do a gradual cleanup and improve the overall 
>>> documentation while doing so.
>>> 
>>> I am -1 w.r.t "host" due to the following reasons:
>>> 
>>> Host term is very generic, it has thousands of usages in Jenkins 
>>> https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing this 
>>> term will require a careful cleanup to avoid confusion in user 
>>> documentation and the codebase
>>> "agent host" is often used to describe target hosts for outbound agents
>>> 
>>> My suggestion would be to consider a "Jenkins server" term. You can see 
>>> that such a term is already used in our codebase, website and on 3rd party 
>>> resources.
>>> 
>>> Best regards,
>>> Oleg
>>> 
>>> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
 
 It is a suggestion for consideration if you would like.
 
 On Jun 11, 2020, at 9:35 PM, Richard Bywater  wrote:
 
 
 Good point. I actually wonder if Manager is a reasonable replacement?
 
 On Fri, 12 Jun 2020 at 16:04, Marky Jackson  wrote:
> 
> The concern with controller may be a conflict with Kubernetes on Jenkins 
> given the same name. This was originally my suggestion but than I 
> remembered I was also part of renaming in that community.
> 
>> On Jun 11, 2020, at 9:02 PM, Richard Bywater  wrote:
>> 
 
 --
 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com.
>>> 
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.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/CAO49JtH%3DNGuf%2BEOoh9gXyOY53vx761aV-w4V07hA7SxwZ%2B_Q1A%40mail.gmail.com.
>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from 

Re: Terminology Updates

[Matt Sicker]

I also like Jenkins Server as a simple name.

Other ideas: JenkinsD (like SystemD or any daemon), Jenkins Principal
(matches the principal/agent paradigm of agents executing code on
behalf of the principal).

On Fri, Jun 12, 2020 at 12:37 PM Vlad Silverman  wrote:
>
> I agree, “Jenkins Server” reflects primary functionality and definitely makes 
> sense.
>
> Thx, Vlad
>
> On Jun 12, 2020, at 10:21 AM, Mark Waite  wrote:
>
> My favorite is Jenkins server.  I'll use whatever term is ultimately 
> selected, but "Jenkins server" is easier for me than "Control Plane".
>
> On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson  
> wrote:
>>
>> My favorite is "Jenkins server" or something like that. There are already 
>> existing usages and it's reasonably explanatory. Something with "manager" 
>> could also work, but I don't find the term as clean and clear.
>>
>> Outside of bias issues, one of the problems with whitelist and blacklist is 
>> that the terms don't really say what they do. Sometimes the interpretation 
>> depends on which way you're looking at it. Somewhat similar to whether a 
>> class hierarchy goes up or down.
>>
>> "AllowList" and "DenyList" are good matching pairs that convey more 
>> semantics about what they do.
>>
>> In other discussions we have noted that not all usages of 
>> whitelist/blacklist fall into the same behavioral meaning. Sometimes we will 
>> need to use different terminology to better convey the meaning.
>>
>> Jeff
>>
>> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>>
>> I am +1 for changing the terminology, and I encourage Jenkins contributors 
>> to participate in this effort. It is not something we could change in a 
>> minute, but we could do a gradual cleanup and improve the overall 
>> documentation while doing so.
>>
>> I am -1 w.r.t "host" due to the following reasons:
>>
>> Host term is very generic, it has thousands of usages in Jenkins 
>> https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing this 
>> term will require a careful cleanup to avoid confusion in user documentation 
>> and the codebase
>> "agent host" is often used to describe target hosts for outbound agents
>>
>> My suggestion would be to consider a "Jenkins server" term. You can see that 
>> such a term is already used in our codebase, website and on 3rd party 
>> resources.
>>
>> Best regards,
>> Oleg
>>
>> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>>>
>>> It is a suggestion for consideration if you would like.
>>>
>>> On Jun 11, 2020, at 9:35 PM, Richard Bywater  wrote:
>>>
>>> 
>>> Good point. I actually wonder if Manager is a reasonable replacement?
>>>
>>> On Fri, 12 Jun 2020 at 16:04, Marky Jackson  wrote:

 The concern with controller may be a conflict with Kubernetes on Jenkins 
 given the same name. This was originally my suggestion but than I 
 remembered I was also part of renaming in that community.

 > On Jun 11, 2020, at 9:02 PM, Richard Bywater  wrote:
 >
>>>
>>> --
>>> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.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/CAO49JtH%3DNGuf%2BEOoh9gXyOY53vx761aV-w4V07hA7SxwZ%2B_Q1A%40mail.gmail.com.
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> 

Re: Terminology Updates

[Vlad Silverman]

I agree, “Jenkins Server” reflects primary functionality and definitely makes 
sense.

Thx, Vlad

> On Jun 12, 2020, at 10:21 AM, Mark Waite  wrote:
> 
> My favorite is Jenkins server.  I'll use whatever term is ultimately 
> selected, but "Jenkins server" is easier for me than "Control Plane".
> 
> On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson  > wrote:
> My favorite is "Jenkins server" or something like that. There are already 
> existing usages and it's reasonably explanatory. Something with "manager" 
> could also work, but I don't find the term as clean and clear.
> 
> Outside of bias issues, one of the problems with whitelist and blacklist is 
> that the terms don't really say what they do. Sometimes the interpretation 
> depends on which way you're looking at it. Somewhat similar to whether a 
> class hierarchy goes up or down.
> 
> "AllowList" and "DenyList" are good matching pairs that convey more semantics 
> about what they do.
> 
> In other discussions we have noted that not all usages of whitelist/blacklist 
> fall into the same behavioral meaning. Sometimes we will need to use 
> different terminology to better convey the meaning.
> 
> Jeff
> 
> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>> I am +1 for changing the terminology, and I encourage Jenkins contributors 
>> to participate in this effort. It is not something we could change in a 
>> minute, but we could do a gradual cleanup and improve the overall 
>> documentation while doing so.
>> 
>> I am -1 w.r.t "host" due to the following reasons:
>> Host term is very generic, it has thousands of usages in Jenkins 
>> https://github.com/search?q=org%3Ajenkinsci+host=Code 
>> . Choosing this 
>> term will require a careful cleanup to avoid confusion in user documentation 
>> and the codebase
>> "agent host" is often used to describe target hosts for outbound agents
>> My suggestion would be to consider a "Jenkins server" term. You can see that 
>> such a term is already used in our codebase 
>> ,
>>  website  
>> and
>>  on 3rd party resources 
>> .
>> 
>> Best regards,
>> Oleg
>> 
>> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>> It is a suggestion for consideration if you would like.
>> 
>>> On Jun 11, 2020, at 9:35 PM, Richard Bywater > wrote:
>>> 
>>> 
>>> Good point. I actually wonder if Manager is a reasonable replacement?
>>> 
>>> On Fri, 12 Jun 2020 at 16:04, Marky Jackson > wrote:
>>> The concern with controller may be a conflict with Kubernetes on Jenkins 
>>> given the same name. This was originally my suggestion but than I 
>>> remembered I was also part of renaming in that community.
>>> 
>>> > On Jun 11, 2020, at 9:02 PM, Richard Bywater > wrote:
>>> > 
>>> -- 
>>> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To 

Blog Offensive Terminology Removal

[Marky Jackson]

To follow the terminology [email sent by 
@slide](https://groups.google.com/d/msg/jenkinsci-dev/CLR55wMZwZ8/uDjgGlnKAQAJ) 
the Advocacy & Outreach SIG met on 6/11/2020 and one action item was to 
revisit all previous Jenkins.io blog post and remove offensive terminology 
where possible. This action item has resulted in the following 
[PR](https://github.com/jenkins-infra/jenkins.io/pull/3447).

It is worth noting:


   - General text with `slave` terminology has been renamed to `agent`
   - Various references could not be changed due to upstream 
   classes/plugin/reference blogs with terminology
   

There are many places the community is working to remove offensive 
terminology, we have made many 
[changes](https://www.jenkins.io/blog/2020/05/06/docker-agent-image-renaming/) 
and there are still more to go.

Thanks kindly.

-- 
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/cae67389-e671-42f4-8af7-009bb9430be7o%40googlegroups.com.

Re: Terminology Updates

[Mark Waite]

My favorite is Jenkins server.  I'll use whatever term is ultimately
selected, but "Jenkins server" is easier for me than "Control Plane".

On Fri, Jun 12, 2020 at 10:13 AM Jeff Thompson 
wrote:

> My favorite is "Jenkins server" or something like that. There are already
> existing usages and it's reasonably explanatory. Something with "manager"
> could also work, but I don't find the term as clean and clear.
>
> Outside of bias issues, one of the problems with whitelist and blacklist
> is that the terms don't really say what they do. Sometimes the
> interpretation depends on which way you're looking at it. Somewhat similar
> to whether a class hierarchy goes up or down.
>
> "AllowList" and "DenyList" are good matching pairs that convey more
> semantics about what they do.
>
> In other discussions we have noted that not all usages of
> whitelist/blacklist fall into the same behavioral meaning. Sometimes we
> will need to use different terminology to better convey the meaning.
>
> Jeff
> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>
> I am +1 for changing the terminology, and I encourage Jenkins contributors
> to participate in this effort. It is not something we could change in a
> minute, but we could do a gradual cleanup and improve the overall
> documentation while doing so.
>
> I am -1 w.r.t "host" due to the following reasons:
>
>- Host term is very generic, it has thousands of usages in Jenkins
>https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing
>this term will require a careful cleanup to avoid confusion in user
>documentation and the codebase
>- "agent host" is often used to describe target hosts for outbound
>agents
>
> My suggestion would be to consider a *"Jenkins server"* term. You can see
> that such a term is already used in our codebase
> ,
> website
> and
> on 3rd party resources
> 
> .
>
> Best regards,
> Oleg
>
> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>>
>> It is a suggestion for consideration if you would like.
>>
>> On Jun 11, 2020, at 9:35 PM, Richard Bywater  wrote:
>>
>> 
>> Good point. I actually wonder if Manager is a reasonable replacement?
>>
>> On Fri, 12 Jun 2020 at 16:04, Marky Jackson  wrote:
>>
>>> The concern with controller may be a conflict with Kubernetes on Jenkins
>>> given the same name. This was originally my suggestion but than I
>>> remembered I was also part of renaming in that community.
>>>
>>> > On Jun 11, 2020, at 9:02 PM, Richard Bywater 
>>> wrote:
>>> >
>>>
>> --
>> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.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/CAO49JtH%3DNGuf%2BEOoh9gXyOY53vx761aV-w4V07hA7SxwZ%2B_Q1A%40mail.gmail.com.

Re: ANN: Jenkins release artifacts uploads blockage on June 09, and a temporary downloads issue

[Oleg Nenashev]

Dear all,

June 12 update: 

   - We continue to work on the accounts migration and will share the next 
   update on Monday
   - Jenkins releases are still blocked. If there are any emergency 
   releases you need to perform, please reply in this thread.

Best regards,
Oleg Nenashev

On Friday, June 12, 2020 at 6:00:32 PM UTC+2, Oleg Nenashev wrote:
>
> Hi Dave,
>
> This is an email from the *Step 2. We’ll reset every user password from 
> the LDAP database*. This one includes a temporary password, and we expect 
> users to change it after they login into the system.
>
> For those who wonder: Yes, the temporary password is sent in plain text as 
> mentioned above. This is how our current password reset system is designed. 
> As other projects, we have a decent amount of technical debt in our 
> infrastructure which we gradually resolve. I have already added changing 
> the account password reset flow to the outage retrospective list, an we 
> will be reviewing what to do there after the outage is fully resolved. 
> Apart from fixing it, migrating to a 3rd-party identity service is on the 
> table for me (Linux Foundation or GitHub).  If anyone is interested to 
> participate and to improve the project, the Jenkins infrastructure team 
>  is always looking for 
> more contributors!
>
> If anyone has concerns about such method and wants to use alternate 
> channels for encrypted password transfer, please send us a message through 
> the Jenkins Infrastructure mailing list from your email registered in 
> Jenkins. In this email please provide your public GPG key so that we can 
> reset a password again in a secure way.
>
> Best regards,
> Oleg
>
> On Friday, June 12, 2020 at 5:07:27 PM UTC+2, Dave Pedu wrote:
>>
>> Hello,
>>
>> I have received an email linking to this thread. However, it contains a 
>> plaintext password for my account, despite this:
>>
>> > There will be no temporary password in these emails, but there will be 
>> information pointing to this thread.
>>
>> Is this email legitimate or am I being phished? Screenshot attached.
>>
>> Thanks,
>> Dave
>>
>> On Thursday, June 11, 2020 at 3:07:01 AM UTC-7, Olblak wrote:
>>>
>>> Dear all,
>>>
>>> We are ready to proceed with restoration of the Jenkins account 
>>> database. Today we are going to restore user LDAP accounts that were 
>>> created since the First of February 2020 based on the data from Jenkins 
>>> Jira and the repository Permission Manager metadata data. We will also 
>>> reset passwords for all users registered in the database.
>>>
>>> Step 1. All users who lost their account will receive an email saying 
>>> that their accounts were re-created. There will be no temporary password in 
>>> these emails, but there will be information pointing to this thread.
>>>
>>> Step 2. We’ll reset every user password from the LDAP database, it is 
>>> more than 100 000 users. Once done, you’ll receive an email telling you 
>>> that your password was reset with a reason containing a link to this mail 
>>> thread.
>>>
>>> Step 3. We will delete accounts of users who requested such deletion 
>>> between February and June 2020. These users were restored from the backup, 
>>> so we have to delete them again.The list of users is based on Jira tickets 
>>> and private messages to the Jenkins Infra officer. If for some reason you 
>>> notice that your account still exists, feel free to raise a ticket in 
>>> Jenkins 
>>> Jira  (project=INFRA, component=account
>>> ).
>>>
>>> Please do not hesitate to contact us using the #jenkins-infra channel on 
>>> Freenode IRC or the Jenkins Infrastructure mailing list if you have any 
>>> questions or suggestions. If you see a security issue related to the 
>>> accounts, please follow the vulnerability reporting guidelines 
>>> .
>>>
>>> Best regards,
>>>
>>> Olivier Vernin && Jenkins Infrastructure Team
>>>
>>>
>>> On Tuesday, 9 June 2020 17:00:25 UTC+2, Oleg Nenashev wrote:

 Dear all,

 As you may have noticed, the release artifact uploads are currently 
 blocked in the Jenkins Artifactory instances (
 https://repo.jenkins-ci.org/). We are doing a security investigation 
 due to a partial user database loss on June 02. Today we blocked releases 
 to the Jenkins artifactory, and there also was a temporary outage of the 
 Artifactory downloads which was a collateral damage of the temporary 
 permissions. You can find more details about it in this Jenkins Infra 
 Thread 
  
 and in this Dev List thread 
 
 .

 Current status:

- 

Downloads are restored for all artifacts on 
https://repo.jenkins-ci.org/, Jenkins core historical releases, 

Re: Terminology Updates

['Gavin Mogan' via Jenkins Developers]

Control plane works but is a mouthfull. Controller works, but as others
pointed out, could easily be confused in the k8s world.

the other two (Host and Server) are way too generic to convey meaning if
you don't know the system.

You could go silly like POTUJ (President of the United Jenkins) or JOTUJ
(Jenkins of the United Jenkins).
Jenkins Brain
Jenkins President
Jenkins CEO
Jenkins Manager
Jenkins Foreman
Jenkins Governor
Jenkins Super / Super Jenkins
Jenkins Taskmaster
Jenkins Boss
Jenkins Leader
Jenkins Overlord

A lot came from
https://www.wordhippo.com/what-is/another-word-for/controller.html

I personally think without the slave context, master is pretty accurate. To
be absolutely honest, if it has more syllables than the current, people are
super likely to stick with the existing wording (Slave-1 vs Agent-2) cause
its easier to say/remember.

Gavin


On Fri, Jun 12, 2020 at 9:13 AM Jeff Thompson 
wrote:

> My favorite is "Jenkins server" or something like that. There are already
> existing usages and it's reasonably explanatory. Something with "manager"
> could also work, but I don't find the term as clean and clear.
>
> Outside of bias issues, one of the problems with whitelist and blacklist
> is that the terms don't really say what they do. Sometimes the
> interpretation depends on which way you're looking at it. Somewhat similar
> to whether a class hierarchy goes up or down.
>
> "AllowList" and "DenyList" are good matching pairs that convey more
> semantics about what they do.
>
> In other discussions we have noted that not all usages of
> whitelist/blacklist fall into the same behavioral meaning. Sometimes we
> will need to use different terminology to better convey the meaning.
>
> Jeff
> On 6/12/20 3:20 AM, Oleg Nenashev wrote:
>
> I am +1 for changing the terminology, and I encourage Jenkins contributors
> to participate in this effort. It is not something we could change in a
> minute, but we could do a gradual cleanup and improve the overall
> documentation while doing so.
>
> I am -1 w.r.t "host" due to the following reasons:
>
>- Host term is very generic, it has thousands of usages in Jenkins
>https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing
>this term will require a careful cleanup to avoid confusion in user
>documentation and the codebase
>- "agent host" is often used to describe target hosts for outbound
>agents
>
> My suggestion would be to consider a *"Jenkins server"* term. You can see
> that such a term is already used in our codebase
> ,
> website
> and
> on 3rd party resources
> 
> .
>
> Best regards,
> Oleg
>
> On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>>
>> It is a suggestion for consideration if you would like.
>>
>> On Jun 11, 2020, at 9:35 PM, Richard Bywater  wrote:
>>
>> 
>> Good point. I actually wonder if Manager is a reasonable replacement?
>>
>> On Fri, 12 Jun 2020 at 16:04, Marky Jackson  wrote:
>>
>>> The concern with controller may be a conflict with Kubernetes on Jenkins
>>> given the same name. This was originally my suggestion but than I
>>> remembered I was also part of renaming in that community.
>>>
>>> > On Jun 11, 2020, at 9:02 PM, Richard Bywater 
>>> wrote:
>>> >
>>>
>> --
>> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com
> 
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: Terminology Updates

[Jeff Thompson]

My favorite is "Jenkins server" or something like that. There are 
already existing usages and it's reasonably explanatory. Something with 
"manager" could also work, but I don't find the term as clean and clear.


Outside of bias issues, one of the problems with whitelist and blacklist 
is that the terms don't really say what they do. Sometimes the 
interpretation depends on which way you're looking at it. Somewhat 
similar to whether a class hierarchy goes up or down.


"AllowList" and "DenyList" are good matching pairs that convey more 
semantics about what they do.


In other discussions we have noted that not all usages of 
whitelist/blacklist fall into the same behavioral meaning. Sometimes we 
will need to use different terminology to better convey the meaning.


Jeff

On 6/12/20 3:20 AM, Oleg Nenashev wrote:
I am +1 for changing the terminology, and I encourage Jenkins 
contributors to participate in this effort. It is not something we 
could change in a minute, but we could do a gradual cleanup and 
improve the overall documentation while doing so.


I am -1 w.r.t "host" due to the following reasons:

  * Host term is very generic, it has thousands of usages in Jenkins
https://github.com/search?q=org%3Ajenkinsci+host=Code.
Choosing this term will require a careful cleanup to avoid
confusion in user documentation and the codebase
  * "agent host" is often used to describe target hosts for outbound
agents

My suggestion would be to consider a *"Jenkins server"* term. You can 
see that such a term is already used in our codebase 
, 
website 
and 
on 3rd party resources 
.


Best regards,
Oleg

On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:

It is a suggestion for consideration if you would like.


On Jun 11, 2020, at 9:35 PM, Richard Bywater > wrote:


Good point. I actually wonder if Manager is a reasonable replacement?

On Fri, 12 Jun 2020 at 16:04, Marky Jackson > wrote:

The concern with controller may be a conflict with Kubernetes
on Jenkins given the same name. This was originally my
suggestion but than I remembered I was also part of renaming
in that community.

> On Jun 11, 2020, at 9:02 PM, Richard Bywater
> wrote:
>

-- 
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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e024d4a9-09e1-ff95-3bbc-a35d486e21ed%40cloudbees.com.

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Tim Jacomb]

Azure high mem:

Standard_D16_v3
vcpu 16
memory 64

AWS:
m5a.xlarge
vcpu 4
memory 16 GiB

I've changed it to: 'm5a.4xlarge' (16CPU, 64 GB ram)
It's 4 times the cost so we'll need to keep an eye on it

Thanks
Tim


On Fri, 12 Jun 2020 at 15:20, Jesse Glick  wrote:

> On Tue, Jun 9, 2020 at 3:59 AM Tim Jacomb  wrote:
> > High mem could possibly do with a change, the AWS ones are much lower
> spec than the Azure ones, thoughts?
>
> Not sure but I just got an unexplained
>
>  EC2 (aws) - High memory ubuntu 18.04  (i-0e7f3896526c7922e) was
> marked offline: Connection was broken: java.io.EOFException
>
> --
> 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/CANfRfr0QsftkUrXP2Z0Ld8HXYn_CJMb4oudqZsKsW02NBn2-ug%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-3BieLPj2GgOLXRAxXxnBeiKvDai0vE0ieRK0c2PP1oVyMHQ%40mail.gmail.com.

Re: ANN: Jenkins release artifacts uploads blockage on June 09, and a temporary downloads issue

[Oleg Nenashev]

Hi Dave,

This is an email from the *Step 2. We’ll reset every user password from the 
LDAP database*. This one includes a temporary password, and we expect users 
to change it after they login into the system.

For those who wonder: Yes, the temporary password is sent in plain text as 
mentioned above. This is how our current password reset system is designed. 
As other projects, we have a decent amount of technical debt in our 
infrastructure which we gradually resolve. I have already added changing 
the account password reset flow to the outage retrospective list, an we 
will be reviewing what to do there after the outage is fully resolved. 
Apart from fixing it, migrating to a 3rd-party identity service is on the 
table for me (Linux Foundation or GitHub).  If anyone is interested to 
participate and to improve the project, the Jenkins infrastructure team 
 is always looking for 
more contributors!

If anyone has concerns about such method and wants to use alternate 
channels for encrypted password transfer, please send us a message through 
the Jenkins Infrastructure mailing list from your email registered in 
Jenkins. In this email please provide your public GPG key so that we can 
reset a password again in a secure way.

Best regards,
Oleg

On Friday, June 12, 2020 at 5:07:27 PM UTC+2, Dave Pedu wrote:
>
> Hello,
>
> I have received an email linking to this thread. However, it contains a 
> plaintext password for my account, despite this:
>
> > There will be no temporary password in these emails, but there will be 
> information pointing to this thread.
>
> Is this email legitimate or am I being phished? Screenshot attached.
>
> Thanks,
> Dave
>
> On Thursday, June 11, 2020 at 3:07:01 AM UTC-7, Olblak wrote:
>>
>> Dear all,
>>
>> We are ready to proceed with restoration of the Jenkins account database. 
>> Today we are going to restore user LDAP accounts that were created since 
>> the First of February 2020 based on the data from Jenkins Jira and the 
>> repository Permission Manager metadata data. We will also reset passwords 
>> for all users registered in the database.
>>
>> Step 1. All users who lost their account will receive an email saying 
>> that their accounts were re-created. There will be no temporary password in 
>> these emails, but there will be information pointing to this thread.
>>
>> Step 2. We’ll reset every user password from the LDAP database, it is 
>> more than 100 000 users. Once done, you’ll receive an email telling you 
>> that your password was reset with a reason containing a link to this mail 
>> thread.
>>
>> Step 3. We will delete accounts of users who requested such deletion 
>> between February and June 2020. These users were restored from the backup, 
>> so we have to delete them again.The list of users is based on Jira tickets 
>> and private messages to the Jenkins Infra officer. If for some reason you 
>> notice that your account still exists, feel free to raise a ticket in 
>> Jenkins 
>> Jira  (project=INFRA, component=account).
>>
>> Please do not hesitate to contact us using the #jenkins-infra channel on 
>> Freenode IRC or the Jenkins Infrastructure mailing list if you have any 
>> questions or suggestions. If you see a security issue related to the 
>> accounts, please follow the vulnerability reporting guidelines 
>> .
>>
>> Best regards,
>>
>> Olivier Vernin && Jenkins Infrastructure Team
>>
>>
>> On Tuesday, 9 June 2020 17:00:25 UTC+2, Oleg Nenashev wrote:
>>>
>>> Dear all,
>>>
>>> As you may have noticed, the release artifact uploads are currently 
>>> blocked in the Jenkins Artifactory instances (
>>> https://repo.jenkins-ci.org/). We are doing a security investigation 
>>> due to a partial user database loss on June 02. Today we blocked releases 
>>> to the Jenkins artifactory, and there also was a temporary outage of the 
>>> Artifactory downloads which was a collateral damage of the temporary 
>>> permissions. You can find more details about it in this Jenkins Infra 
>>> Thread 
>>>  and 
>>> in this Dev List thread 
>>> 
>>> .
>>>
>>> Current status:
>>>
>>>- 
>>>
>>>Downloads are restored for all artifacts on 
>>>https://repo.jenkins-ci.org/, Jenkins core historical releases, 
>>>Remoting library and Windows Service Wrapper which were among ones 
>>> reported 
>>>by Jenkins users.
>>>- 
>>>
>>>Uploads: Jenkins artifact uploads are blocked for the most of 
>>>Jenkins plugin maintainers and contributors. It affects releases of 
>>> Jenkins 
>>>plugins, Jenkins core and modules, developer tools and all libraries 
>>> hosted 
>>>on https://repo.jenkins-ci.org/. Incremental and Snapshot 
>>>deployments are not affected.
>>> 

Plugin adoption request: NUnit

[Shin-ichi Morita]

Hi Team,

I would like to adopt NUnit plugin and request commit access.

My current interest is fixing JENKINS-50162. I submitted this pull request 
about 20 days ago without noticing it is marked for adoption.

* Link to a plugin you want to adopt: https://github.com/jenkinsci/nunit-plugin
* Link(s) to pull requests you want to deliver: 
https://github.com/jenkinsci/nunit-plugin/pull/23
* Your GitHub username/id: s-morita-being
* Your Jenkins infrastructure account id: smorita

Thank you in advance,

Shin-ichi Morita


-- 
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/87c58adf-c70d-4fbf-ba89-d8e3ff71fccdo%40googlegroups.com.

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

[Jesse Glick]

On Tue, Jun 9, 2020 at 3:59 AM Tim Jacomb  wrote:
> High mem could possibly do with a change, the AWS ones are much lower spec 
> than the Azure ones, thoughts?

Not sure but I just got an unexplained

 EC2 (aws) - High memory ubuntu 18.04  (i-0e7f3896526c7922e) was
marked offline: Connection was broken: java.io.EOFException

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

Re: Proposal: Jenkins CDF Graduation July 28th

[Oleg Nenashev]

I have started a Google Doc with a 
checklist: 
https://docs.google.com/document/d/1Ldmtny6OfEtQlCqdFWqq9Z25cxkZFX6yNiRqOOxo77c/edit?usp=sharing
Please feel free to contribute and suggest changes!

Best regards,
Oleg

On Friday, June 12, 2020 at 12:16:35 AM UTC+2, Marky Jackson wrote:
>
> +1 from me
>
> On Jun 11, 2020, at 2:39 PM, Tracy Miranda  > wrote:
>
> All,
>
> Last year Jenkins became a CD.Foundation  
> project. The Technical Oversight Committee (TOC) of CDF set out a project 
> lifecycle 
> 
>  
> for projects as part of the governance model. CDF is proposing Jenkins be 
> the first project to go through the process and "graduate" i.e. demonstrate 
> it has met the acceptance criteria 
> 
> .
>
> Dan Lorenc, the current TOC Chair, joined the Jenkins Governance meeting 
>  this month for an overview of the process 
> and we had a discussion around the criteria. In short, there are a few 
> housekeeping things to do for Jenkins to graduate, and the process has 
> already been beneficial to the project health (e.g. helping identify that 
> we need to strengthen the triage team, update Code-of-Conduct, etc). 
> Project graduation will also be an opportunity to promote the Jenkins 
> project via CDF channels and highlight how the project goes from strength 
> to strength. 
>
> I would like to propose that the Jenkins Community commit to graduating by 
> the end of July, i.e. on July 28th 2020 at the CDF TOC meeting, we show how 
> we've met the criteria and ask for a vote. 
>
> (Note: this schedule allows CDF to graduate Jenkins as the first project 
> but also in a timely way so other CDF projects may also graduate in 2020.)
>
> Please go ahead and vote/comment on this proposal.
>
> Regards,
>
> Tracy
>
>
> -- 
> 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/CACTaz6q74FSexfzGqa1BVRXVP-R%2BD161LXALOxL-bd2BrrO7Dg%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/e483e68c-08de-4843-af21-0c00b0a5d574o%40googlegroups.com.

Re: Proposal: Public community-driven roadmap for the Jenkins project

[Oleg Nenashev]

I have updated https://github.com/jenkins-infra/jenkins.io/pull/3444. Now 
it includes initiative labels and filtering support (pardon my JavaScript).
Among major changes, Documentation, Infrastructure and Advocacy/Outreach 
categories have been largely merged into other groups.

Any feedback will be appreciated!

Filtering example:




On Wednesday, June 10, 2020 at 9:41:08 PM UTC+2, Marky Jackson wrote:
>
> This is great! Thank you for all that you do.
>
> On Jun 10, 2020, at 12:15 PM, Oleg Nenashev  > wrote:
>
> Hi all,
>
> Just to provide some updates, we have had a few roadmap reviews at the 
> Jenkins Governance meetings, and we have also collected roadmap feedback 
> from all special interest groups and sub-projects. We have been less 
> successful with plugin maintainer communications, but I hope to address it 
> in the coming week by hosting an online meetup and, maybe, reaching out to 
> maintainers through the Jenkins contributor newsletter which I would like 
> to establish.Current roadmap can be found here: 
> https://www.jenkins.io/project/roadmap/
>
> I would like to suggest a few changes there based on the experience:
>
>1. Introduce a new "Preview" status. We have any initiatives which are 
>stuck in Current but which are available to users for preview, e.g. 
>WebSockets support (JEP-223), new Windows Installer, and so on. Moving it 
>to a new category would allow to highlight the preview status and, 
>hopefully, to facilitate feedback
>   - I created https://github.com/jenkins-infra/jenkins.io/pull/3444 for 
>   review
>2. Introduce labels of initiatives (e.g. "feature", "documentation", 
>"service", "outreach-program", etc.)
>   - Each initiative will be able to have multiple categories. There 
>   will be a JavaScript-powered filter which will allow filtering 
> categories
>   - "Documentation" and "Outreach Programs" sections would be largely 
>   merged into user-focused categories on the roadmap.
>  - For example, Jenkins UI/UX Hackfest would be in the "User 
>  Experience" group while having an "outreach-program" label
>   
> Would appreciate your feedback about these proposals.
>
> Thanks in advance,
> Oleg
>
>
> On Monday, April 6, 2020 at 8:10:34 PM UTC+2, Jon Brohauge wrote:
>>
>> Totally love the roadmap. Sincerely missed in most software.
>>
>> Rgds
>> Jon
>>
>
> -- 
> 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/46eca5da-9ef2-454e-a83c-198234f20603o%40googlegroups.com
>  
> 
> .
>
>
>

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

Re: Terminology Updates

[Oleg Nenashev]

I am +1 for changing the terminology, and I encourage Jenkins contributors 
to participate in this effort. It is not something we could change in a 
minute, but we could do a gradual cleanup and improve the overall 
documentation while doing so.

I am -1 w.r.t "host" due to the following reasons:

   - Host term is very generic, it has thousands of usages in Jenkins 
   https://github.com/search?q=org%3Ajenkinsci+host=Code. Choosing 
   this term will require a careful cleanup to avoid confusion in user 
   documentation and the codebase
   - "agent host" is often used to describe target hosts for outbound agents

My suggestion would be to consider a *"Jenkins server"* term. You can see 
that such a term is already used in our codebase 
, 
website 
and
 
on 3rd party resources 

.

Best regards,
Oleg

On Friday, June 12, 2020 at 6:42:34 AM UTC+2, Marky Jackson wrote:
>
> It is a suggestion for consideration if you would like.
>
> On Jun 11, 2020, at 9:35 PM, Richard Bywater  > wrote:
>
> 
> Good point. I actually wonder if Manager is a reasonable replacement?
>
> On Fri, 12 Jun 2020 at 16:04, Marky Jackson  > wrote:
>
>> The concern with controller may be a conflict with Kubernetes on Jenkins 
>> given the same name. This was originally my suggestion but than I 
>> remembered I was also part of renaming in that community.
>>
>> > On Jun 11, 2020, at 9:02 PM, Richard Bywater > > wrote:
>> > 
>>
> -- 
> 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/CAAy0hwcrbnGua2b3sHamE2AG1r3z8cXBxA02%2B4NrQHMWqQjzyg%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/4ffdf650-4bb4-4878-a629-4e49c3ac06b5o%40googlegroups.com.

Re: Adopt parameterized-trigger-plugin commit access

[Oleg Nenashev]

Hi Olivier,

I am +1 for that as a former plugin maintainer, thanks a lot for standing 
up!
I have granted you permissions in the repository. Please let me know if you 
want to be a default assignee in Jira.

Best regards,
Oleg


On Friday, June 12, 2020 at 8:24:28 AM UTC+2, Olivier Lamy wrote:
>
> Hi
> As it's in "adopt me" mode, I'd like to make some changes in this plugin
> https://github.com/jenkinsci/parameterized-trigger-plugin
> It's essentially some dependencies upgrade and some cleanup
> github id: olamy.
> Jenkins infra id: olamy
> Thanks
> Regards
> -- 
> Olivier Lamy
>

-- 
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/3b32497d-43cc-465b-a064-2b696500b335o%40googlegroups.com.

Adopt parameterized-trigger-plugin commit access

[Olivier Lamy]

Hi
As it's in "adopt me" mode, I'd like to make some changes in this plugin
https://github.com/jenkinsci/parameterized-trigger-plugin
It's essentially some dependencies upgrade and some cleanup
github id: olamy.
Jenkins infra id: olamy
Thanks
Regards
-- 
Olivier Lamy

-- 
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/CAPoyBqSkbujy6Qawf%2BzMc4X354SGgC%2BS6_tfhzJHTGU9RiPukg%40mail.gmail.com.

Re: External Fingerprint Storage for Jenkins

[Sumit Sarin]

Hi all,
Yesterday we had a Cloud Native SIG meeting where we presented the demo for 
the External Fingerprint Storage project and had some insightful 
discussions in regards to making the project even better. I immensely thank 
everyone who participated!

If somebody wanted to attend but missed it, the recording 
 and slides 

 
are linked. 
Also the PR for this project's JEP 
 is also ready.

Thanks again,

Best Regards,
Sumit Sarin

On Tuesday, 9 June 2020 14:22:05 UTC+5:30, Sumit Sarin wrote:
>
> Hi all,
> It brings me great joy in introducing the Jenkins community to one of the 
> ongoing Google Summer of Code (GSoC) projects: *External Fingerprint 
> Storage for Jenkins*.
>
> File fingerprinting is a way to track which version of a file is being 
> used by a job/build, making dependency tracking easy. The fingerprint 
> engine of Jenkins can track usages of artifacts, credentials, files, etc. 
> within the system. It does this by maintaining a local XML-based database. 
> This leads to dependence on the physical disk of the Jenkins master. Hence, 
> the core idea of this project is to *extend Jenkins core to support 
> storing of fingerprints in an external storage*, which would also allow 
> tracking them across the entire CI/CD flow. 
>
> The goals of this project include:
>
>- Building a *pluggable storage engine*, which would allow 
>fingerprints to be stored in external storages managed by storage system 
>specific plugins.
>- Reference implementation in the form of *Redis backed fingerprint 
>storage plugin*.
>- Allowing *fingerprints to be traced across Jenkins instances* 
>(possibly via another plugin)
>
> The code for this project currently lives in two places: 
>
>1. PR introducing pluggable storage in Jenkins core 
>.
>2. Redis Fingerprint Storage Plugin 
> (Reference 
>implementation)
>
> So whilst we are working towards this project, we would love to receive 
> community suggestions and feedback as to how we can make this project even 
> better, and how maybe we can solve some problems for the users/developers. 
> Here is a link to our draft design document 
> ,
>  
> which is soon to be converted into a JEP.
>
> I would also like to invite everyone interested to join us for a demo of 
> the project at the Cloud Native SIG Meeting, for which the doodle 
>  is open for voting.
>
> All other information regarding the project can be found at our up to date 
> project 
> page 
> 
> .
>
> Best Regards,
> Sumit Sarin
>
>
>
>
>

-- 
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/d6aab8d9-a265-4c70-90be-e3a61224c538o%40googlegroups.com.