How do I get the Run/Job of a TimerTrigger?

[Michael Carter]

So what I'm doing.  Trying to make a SimpleParameterDefinition persistent 
by looking up the previous success full build and using it's parameters as 
the default for the timer triggered job.

hudson.triggers.Trigger#checkTriggers: hudson.triggers.TimerTrigger.run() 
failed for org.jenkinsci.plugins.workflow.job.WorkflowJob@7acbb62c

So Stapler.getCurrentRequest().findAncestorObject(Job.class); doesn't work 
inside the getDefaultParameterValue

How do I get at the Job definition here?

-- 
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/670387dd-1307-4428-91ad-e59f2bb258dan%40googlegroups.com.

Re: multiple recordIssues for parallel steps

[Ullrich Hafner]

SpotBugs actually works on the byte code level so there might be some different 
results due to the different compiler results (in theory). But I doubt that you 
get different results in practice. 
In Jenkins CI we also record issues only for the first environment and skip it 
for subsequent calls (at least the Jenkins Plugin is not running, maven still 
runs mvn verify).


> Am 29.11.2020 um 23:20 schrieb Jesse Glick :
> 
> I would disable SpotBugs, Checkstyle, and PMD on all but one branch, since 
> the results should be a function of the source code, not the build 
> environment.
> 
> -- 
> 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/CANfRfr3UsYEbwsgHVm8kOU5jsezBmxwUYYWShJbzyvSfc9-Cgw%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/D9403F7D-8AB5-4853-9ADD-02A3B173DA19%40gmail.com.

Re: Jenkins Operator managed service name (sublicensing)

[Richard Bywater]

I agree that I think use of a company name within the title is appropriate
if it's not part of a base Jenkins community offering. e.g. Jenkins
Operator Service might be ok for an official Jenkins community offering of
an Operator Service but not for an offering by a particular company.

Regarding the Azure Marketplace, is it worth starting to look at someone
(guessing it would be the Governance Board?) starting to try and contact
the vendors who are supplying the marketplace items to alert them that the
names should really be changed (and then starting to look to enforce it
later down the track)?

Richard.

On Mon, 30 Nov 2020 at 11:31, Oleg Nenashev  wrote:

> Hi Pawel,
>
> TBH I am not sure "Jenkins Operator Service" would be approved, it is too
> generic. I would definitely hesitate voting for it. There is no precedent
> of such name being approved before for product names, only for
> community-focused events and :
> https://www.jenkins.io/project/trademark/approved-usage/ . Before the
> Linux Foundation trademark guidelines were adopted, the product names
> commonly had the "COMPANY_NAME Jenkins Something" or the "Jenkins Something
> by COMPANY_NAME" naming pattern. It's probably something you could consider.
>
> Feedback/suggestions from others would be appreciated.
>
> P.S: As we discussed a few months ago, product naming on public cloud
> marketplaces is a mess at the moment:
> https://azuremarketplace.microsoft.com/en-us/marketplace/apps?page=1=jenkins
> . So we still need to maintain a balance in trademark sublicense reviews so
> that good faith requests do not create disadvantages compared to vendors
> who do not submit trademark sublicense requests. Maybe a listing of
> commercial offerings on our site could help with that (similar to
> https://wiki.jenkins.io/display/JENKINS/Commercial+Support which still
> needs to be moved to jenkins.io)
>
> BR, Oleg
>
> On Thursday, November 26, 2020 at 1:38:18 PM UTC+1 pdo...@virtuslab.com
> wrote:
>
>> You are right. In case of this name we would need to pursue the approval
>> from Kubernetes organization.
>>
>> If possible I think ideal name (from our perspective) would be *Jenkins
>> Operator* *Service*. I think we could try to agree on some commitment
>> from our side when it comes to making sure Jenkins & Kubernetes is a great
>> match and is being well maintained (but that's obviously something that
>> would need to be further discuss, if even viable from your side). Totally
>> understand if this is not possible though.
>>
>>
>>
>> On Thursday, November 26, 2020 at 12:21:10 PM UTC+1 Oleg Nenashev wrote:
>>
>>> Hi Pawel,
>>>
>>> Thanks for the follow-up and for looking for an alternative name. I have
>>> added the trademark usage request review/approval to the Dec 02
>>> Governance Meeting agenda
>>> .
>>> Let's see whether we can reach a consensus in the email list ahead of the
>>> meeting.
>>>
>>> One challenge for the naming is that the suggested name (Kubernetes
>>> Operator Service for Jenkins) uses not only the Jenkins trademark, but also
>>> "Kubernetes" which is also the Linux Foundation trademark subject to the
>>> same trademark usage rules. It is less of a concern for the Jenkins
>>> community, but please keep in mind that our approval, if granted, will
>>> address only the "Jenkins" trademark usage. The "Kubernetes" trademark
>>> usage is not something we can approve or reject, it is a subject for a
>>> separate discussion with the trademark owner.
>>>
>>> Best regards,
>>> Oleg Nenashev
>>>
>>> On Thursday, November 26, 2020 at 12:01:17 PM UTC+1 pdo...@virtuslab.com
>>> wrote:
>>>
 Hi Jenkinsci Board

 We are the authors of OSS
 https://github.com/jenkinsci/kubernetes-operator project.

 We started building commercial managed offering based on this project -
 managed version available in Azure marketplace. Given that the project is
 commercial offering built on top of OSS *Jenkins Operator *we wanted
 to name it *Jenkins Operator Service *(which we thought describes
 pretty well what it is, managed service for OSS project).

 Our initial draft of the offering is here:
 https://jenkins-operator.com/ (currently private preview).

 Given trademark guidelines here:
 https://www.linuxfoundation.org/trademark-usage/ it seems however that
 it might be worth to reconsider the suggested name and change it to
 something like: *Kubernetes Operator Service for Jenkins *

 Is there any way we could apply for sublicensing for using the
 "Jenkins" word within our product offering naming? If so, what would we
 need to do to apply?

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

Re: Jenkins Operator managed service name (sublicensing)

[Oleg Nenashev]

Hi Pawel,

TBH I am not sure "Jenkins Operator Service" would be approved, it is too 
generic. I would definitely hesitate voting for it. There is no precedent 
of such name being approved before for product names, only for 
community-focused events and 
: https://www.jenkins.io/project/trademark/approved-usage/ . Before the 
Linux Foundation trademark guidelines were adopted, the product names 
commonly had the "COMPANY_NAME Jenkins Something" or the "Jenkins Something 
by COMPANY_NAME" naming pattern. It's probably something you could consider.

Feedback/suggestions from others would be appreciated.

P.S: As we discussed a few months ago, product naming on public cloud 
marketplaces is a mess at the 
moment: 
https://azuremarketplace.microsoft.com/en-us/marketplace/apps?page=1=jenkins
 
. So we still need to maintain a balance in trademark sublicense reviews so 
that good faith requests do not create disadvantages compared to vendors 
who do not submit trademark sublicense requests. Maybe a listing of 
commercial offerings on our site could help with that (similar to 
https://wiki.jenkins.io/display/JENKINS/Commercial+Support which still 
needs to be moved to jenkins.io)

BR, Oleg

On Thursday, November 26, 2020 at 1:38:18 PM UTC+1 pdo...@virtuslab.com 
wrote:

> You are right. In case of this name we would need to pursue the approval 
> from Kubernetes organization. 
>
> If possible I think ideal name (from our perspective) would be *Jenkins 
> Operator* *Service*. I think we could try to agree on some commitment 
> from our side when it comes to making sure Jenkins & Kubernetes is a great 
> match and is being well maintained (but that's obviously something that 
> would need to be further discuss, if even viable from your side). Totally 
> understand if this is not possible though. 
>
>
>
> On Thursday, November 26, 2020 at 12:21:10 PM UTC+1 Oleg Nenashev wrote:
>
>> Hi Pawel, 
>>
>> Thanks for the follow-up and for looking for an alternative name. I have 
>> added the trademark usage request review/approval to the Dec 02 
>> Governance Meeting agenda 
>> .
>>  
>> Let's see whether we can reach a consensus in the email list ahead of the 
>> meeting.
>>
>> One challenge for the naming is that the suggested name (Kubernetes 
>> Operator Service for Jenkins) uses not only the Jenkins trademark, but also 
>> "Kubernetes" which is also the Linux Foundation trademark subject to the 
>> same trademark usage rules. It is less of a concern for the Jenkins 
>> community, but please keep in mind that our approval, if granted, will 
>> address only the "Jenkins" trademark usage. The "Kubernetes" trademark 
>> usage is not something we can approve or reject, it is a subject for a 
>> separate discussion with the trademark owner.
>>
>> Best regards,
>> Oleg Nenashev
>>
>> On Thursday, November 26, 2020 at 12:01:17 PM UTC+1 pdo...@virtuslab.com 
>> wrote:
>>
>>> Hi Jenkinsci Board
>>>
>>> We are the authors of OSS 
>>> https://github.com/jenkinsci/kubernetes-operator project. 
>>>
>>> We started building commercial managed offering based on this project - 
>>> managed version available in Azure marketplace. Given that the project is 
>>> commercial offering built on top of OSS *Jenkins Operator *we wanted to 
>>> name it *Jenkins Operator Service *(which we thought describes pretty 
>>> well what it is, managed service for OSS project). 
>>>
>>> Our initial draft of the offering is here: https://jenkins-operator.com/ 
>>> (currently 
>>> private preview).
>>>
>>> Given trademark guidelines here: 
>>> https://www.linuxfoundation.org/trademark-usage/ it seems however that 
>>> it might be worth to reconsider the suggested name and change it to 
>>> something like: *Kubernetes Operator Service for Jenkins *
>>>
>>> Is there any way we could apply for sublicensing for using the "Jenkins" 
>>> word within our product offering naming? If so, what would we need to do to 
>>> apply? 
>>>
>>

-- 
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/1a843791-216c-4e15-8f3f-2da0bc680743n%40googlegroups.com.

Re: built-on-column-plugin Adoption

[Mark Waite]

Since the request was 11 days ago, it seems we're very near the completion
of the two week adoption period.  +1 from me for having Brian as the
maintainer in 3 days when the two weeks elapsed time is completed for the
adoption request.

On Sun, Nov 29, 2020 at 3:01 PM Oleg Nenashev 
wrote:

> I have added the former plugin maintainer, Henk van Voorthuijsen, to Cc.
> I am not sure this email is still active after 9 years, but just in case.
>
>
> On Wed, Nov 18, 2020 at 5:50 PM Oleg Nenashev 
> wrote:
>
>> Hi Brian,
>>
>> Thanks for your interest! I am definitely +1 for reviving this plugin.
>> The last release was in 2011, so this plugin needs some updates.
>> Not sure whether we should go through the adoption process in this case,
>> would appreciate feedback from others
>>
>> Best regards,
>> Oleg
>>
>>
>> On Wednesday, November 18, 2020 at 4:56:56 PM UTC+1 br...@hashvault.io
>> wrote:
>>
>>> Jenkins community,
>>>
>>> Oleg and I briefly talked about having me adopt the
>>> built-on-column-plugin.
>>>
>>> I've been contributing to Jenkins for over a month. Most of my
>>> contributions have been documentation updates in alignment with migrating
>>> documentation from the old wiki to GitHub.
>>>
>>> I want to get more involved, and think that adopting a plugin is a step
>>> in the right direction.
>>>
>>> - plugin: https://github.com/jenkinsci/built-on-column-plugin
>>> - PRs:
>>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/5
>>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/4
>>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/3
>>> - GitHub username: https://github.com/bromps
>>> - Jenkins infra ID: dethecus
>>>
>>> Thank you,
>>> Brian
>>>
>> --
>> 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/94AxMQZ-DbI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/1dc489f8-fbe1-4b1a-b43e-40bf9d063e6fn%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/CAPfivLB52_FZS3nE6sERLwpj95190jSqs%3DCt6w%3Dj%2BONwD4c7Yg%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/CAO49JtHCDa4-YyMhgUvxKns3SDXNnAViga7-S1JNxu0fdt5kSQ%40mail.gmail.com.

Re: built-on-column-plugin Adoption

[Oleg Nenashev]

I have added the former plugin maintainer, Henk van Voorthuijsen, to Cc.
I am not sure this email is still active after 9 years, but just in case.


On Wed, Nov 18, 2020 at 5:50 PM Oleg Nenashev 
wrote:

> Hi Brian,
>
> Thanks for your interest! I am definitely +1 for reviving this plugin. The
> last release was in 2011, so this plugin needs some updates.
> Not sure whether we should go through the adoption process in this case,
> would appreciate feedback from others
>
> Best regards,
> Oleg
>
>
> On Wednesday, November 18, 2020 at 4:56:56 PM UTC+1 br...@hashvault.io
> wrote:
>
>> Jenkins community,
>>
>> Oleg and I briefly talked about having me adopt the
>> built-on-column-plugin.
>>
>> I've been contributing to Jenkins for over a month. Most of my
>> contributions have been documentation updates in alignment with migrating
>> documentation from the old wiki to GitHub.
>>
>> I want to get more involved, and think that adopting a plugin is a step
>> in the right direction.
>>
>> - plugin: https://github.com/jenkinsci/built-on-column-plugin
>> - PRs:
>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/5
>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/4
>>   - https://github.com/jenkinsci/built-on-column-plugin/pull/3
>> - GitHub username: https://github.com/bromps
>> - Jenkins infra ID: dethecus
>>
>> Thank you,
>> Brian
>>
> --
> 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/94AxMQZ-DbI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/1dc489f8-fbe1-4b1a-b43e-40bf9d063e6fn%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/CAPfivLB52_FZS3nE6sERLwpj95190jSqs%3DCt6w%3Dj%2BONwD4c7Yg%40mail.gmail.com.

Re: Jenkins Governance Meeting, Nov 18, 2020

[Ullrich Hafner]

This is a good idea! 

> Am 29.11.2020 um 21:53 schrieb Oleg Nenashev :
> 
> Hi all,
> 
> Thanks to everyone for the follow-ups. Based on the conversation, I suggest 
> to do two things:
> Start the governance meeting threads early, at least with a 24hrs advance. In 
> this thread I can put explicit reminder for people to RSVP to the governance 
> meeting, just by adding their name to the agenda Google Doc. It should be 
> better than Google Calendar where recurrent meeting participation responses 
> are often confusing. I will adopt this process for the meetings I host, so we 
> can see whether it works.
> Start the Doodle for the new Jenkins Governance Meeting time. I will prepare 
> the draft for the meeting on Wednesday so that we can review the suggested 
> slots. Floating time can be also an option, especially if we consider doing a 
> periodic APAC-friendly meeting.
> Best regards,
> Oleg
> 
> 
> On Thursday, November 19, 2020 at 1:00:33 PM UTC+1 slide wrote:
> Hi Oleg,
> 
> First, my sincere apologies for not being at the meeting and making you stay 
> at the office away from your family. Family is super important to me and that 
> time is very important and I am sorry I didn't respond to let you know that I 
> wouldn't be at the meeting. After the recent daylight saving time change, I 
> have a work meeting conflict every week now. I have updated my availability 
> for the rest of the meetings that I will not be able to attend.
> 
> Regards,
> 
> Alex
> 
> On Thu, Nov 19, 2020 at 1:37 AM Tim Jacomb  > wrote:
> The time also means I cant attend, so +1 for reviewing another time
> 
> On Thu, 19 Nov 2020 at 08:18, Oleg Nenashev  > wrote:
> As discussed a few months ago, we will revise the meeting time once the 2020 
> elections are over
> Since we have candidates from APAC, the meeting approach may require 
> significant changes, not just choosing the least worst timeslot for everyone
> 
> On Thu, Nov 19, 2020 at 9:14 AM 'Olblak' via Jenkins Developers 
>  > wrote:
> Hi  Oleg,
> 
> I am sorry to hear about that, that time is definitely really bad for me as 
> well.  
> 
> On Wed, Nov 18, 2020, at 7:15 PM, Oleg Nenashev wrote:
>> The meeting did not happen, because it was only me on the call. I kindly ask 
>> board members and officers to reject the meeting invitations in their 
>> calendars if they do not plan to attend. The timing for these meeting is 
>> quite bad for me, and it puts pressure on my family obligations. If I know 
>> that nobody plans to join in advance, I won't be staying in the office for a 
>> few extra hours, and spend them with my family instead. Thanks for 
>> understanding.
>> 
>> On Wednesday, November 18, 2020 at 6:10:33 PM UTC+1 Oleg Nenashev wrote:
>> Hi all,
>> 
>> In 1 hour we will have a regular Jenkins Governance Meeting (starts at 6PM 
>> UTC). Everyone is welcome to join us and to participate in the discussion. 
>> Meeting link: 
>> https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09 
>>  
>> 
>> Draft agenda:
>> News!
>> Jenkins elections status update
>> LTS schedule update
>> Google Summer of Code 2021
>> Jenkins K8s Operator updates
>> If you would like to add more topics, please suggest changes here 
>> .
>> 
>> Best regards,
>> 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/18072109-74c2-4cd6-9faf-15c04700826bn%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/4v01zfG5moM/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/d6468cf2-40c4-47b5-94a1-24f1e1e42b74%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-de...@googlegroups.com 
> .
> To view this discussion on the 

Jenkins Governance Meeting on Dec 02, 2020

[Oleg Nenashev]

Hi all,

On Dec 02 we will have the regular governance meeting. Taking the 
conversation in this thread 
, I have created a 
Doodle to see if there are better slots for a one-off meeting on Dec 02. If 
no consensus found, I suggest doing it at 6PM UTC as usual. Would 
appreciate 
votes! https://doodle.com/poll/epaccs4nkqkamz7e?utm_source=poll_medium=link

Current agenda draft (see the links and suggest changes here 

):

   - News!
  - LTS RC testing status and the winter break
  - GSoC 2021
   - Jenkins elections status update
   - Jenkins 3.0 suggestion
   - Jenkins K8s Operator Governance updates
   - Trademark sublicense request by VirtusLab
   - Selecting New Jenkins Governance Meeting slots

Best regards,
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/121cf75e-3fb7-4239-85ab-2534ad306a30n%40googlegroups.com.

Re: Jenkins 2.263.1 LTS RC testing started

[Oleg Nenashev]

Hi, thanks for publishing the release candidate! Also, changelog draft from 
Mark Waite: https://github.com/jenkins-infra/jenkins.io/pull/3985

Unfortunately I have not been able to test the RC this weekend. I can only 
say that I have deployed to 2.263 in my home Jenkins setup and bumped 
Jenkinsfile Runner there to 2.263 as well. This release was good. I may not 
be able to test the RC in time, sorry.

BR, Oleg



On Tuesday, November 24, 2020 at 11:53:03 AM UTC+1 ogondza wrote:

> Hello everyone,
>
> Latest LTS RC was made public and it is ready to be tested. Final 
> release is scheduled for 2020-12-02.
>
> Please, report your findings in this thread.
>
> Download bits from 
> http://mirrors.jenkins-ci.org/war-stable-rc/2.263.1/jenkins.war 
> (sha256:679d2436eb1b537fe378905306cdbf904e2a540dc39f0718aa6cfc68c9bff107)
>
> Thanks!
> -- 
> oliver
>

-- 
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/3b054b41-a56a-43d0-83af-7e2f4fdf0cf1n%40googlegroups.com.

Re: Jenkins Governance Meeting, Nov 18, 2020

[Marky Jackson]

+1

> On Nov 29, 2020, at 12:53 PM, Oleg Nenashev  wrote:
> 
> Hi all,
> 
> Thanks to everyone for the follow-ups. Based on the conversation, I suggest 
> to do two things:
> Start the governance meeting threads early, at least with a 24hrs advance. In 
> this thread I can put explicit reminder for people to RSVP to the governance 
> meeting, just by adding their name to the agenda Google Doc. It should be 
> better than Google Calendar where recurrent meeting participation responses 
> are often confusing. I will adopt this process for the meetings I host, so we 
> can see whether it works.
> Start the Doodle for the new Jenkins Governance Meeting time. I will prepare 
> the draft for the meeting on Wednesday so that we can review the suggested 
> slots. Floating time can be also an option, especially if we consider doing a 
> periodic APAC-friendly meeting.
> Best regards,
> Oleg
> 
> 
>> On Thursday, November 19, 2020 at 1:00:33 PM UTC+1 slide wrote:
>> Hi Oleg,
>> 
>> First, my sincere apologies for not being at the meeting and making you stay 
>> at the office away from your family. Family is super important to me and 
>> that time is very important and I am sorry I didn't respond to let you know 
>> that I wouldn't be at the meeting. After the recent daylight saving time 
>> change, I have a work meeting conflict every week now. I have updated my 
>> availability for the rest of the meetings that I will not be able to attend.
>> 
>> Regards,
>> 
>> Alex
>> 
>>> On Thu, Nov 19, 2020 at 1:37 AM Tim Jacomb  wrote:
>>> The time also means I cant attend, so +1 for reviewing another time
>>> 
 On Thu, 19 Nov 2020 at 08:18, Oleg Nenashev  wrote:
 As discussed a few months ago, we will revise the meeting time once the 
 2020 elections are over
 Since we have candidates from APAC, the meeting approach may require 
 significant changes, not just choosing the least worst timeslot for 
 everyone
 
> On Thu, Nov 19, 2020 at 9:14 AM 'Olblak' via Jenkins Developers 
>  wrote:
> Hi  Oleg,
> 
> I am sorry to hear about that, that time is definitely really bad for me 
> as well.  
> 
>> On Wed, Nov 18, 2020, at 7:15 PM, Oleg Nenashev wrote:
>> The meeting did not happen, because it was only me on the call. I kindly 
>> ask board members and officers to reject the meeting invitations in 
>> their calendars if they do not plan to attend. The timing for these 
>> meeting is quite bad for me, and it puts pressure on my family 
>> obligations. If I know that nobody plans to join in advance, I won't be 
>> staying in the office for a few extra hours, and spend them with my 
>> family instead. Thanks for understanding.
>> 
>> On Wednesday, November 18, 2020 at 6:10:33 PM UTC+1 Oleg Nenashev wrote:
>> Hi all,
>> 
>> In 1 hour we will have a regular Jenkins Governance Meeting (starts at 
>> 6PM UTC). Everyone is welcome to join us and to participate in the 
>> discussion. Meeting link: 
>> https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09 
>> 
>> Draft agenda:
>> News!
>> Jenkins elections status update
>> LTS schedule update
>> Google Summer of Code 2021
>> Jenkins K8s Operator updates
>> If you would like to add more topics, please suggest changes here.
>> 
>> Best regards,
>> 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/18072109-74c2-4cd6-9faf-15c04700826bn%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/4v01zfG5moM/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/d6468cf2-40c4-47b5-94a1-24f1e1e42b74%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-de...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBcjSGSsUaipgGNeAW25XteH%2BnPrx-MDc2j0GU6AZN6Og%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 

Re: Jenkins Governance Meeting, Nov 18, 2020

[Oleg Nenashev]

Hi all,

Thanks to everyone for the follow-ups. Based on the conversation, I suggest 
to do two things:

   - Start the governance meeting threads early, at least with a 24hrs 
   advance. In this thread I can put explicit reminder for people to RSVP to 
   the governance meeting, just by adding their name to the agenda Google Doc. 
   It should be better than Google Calendar where recurrent meeting 
   participation responses are often confusing. I will adopt this process for 
   the meetings I host, so we can see whether it works.
   - Start the Doodle for the new Jenkins Governance Meeting time. I will 
   prepare the draft for the meeting on Wednesday so that we can review the 
   suggested slots. Floating time can be also an option, especially if we 
   consider doing a periodic APAC-friendly meeting.

Best regards,
Oleg


On Thursday, November 19, 2020 at 1:00:33 PM UTC+1 slide wrote:

> Hi Oleg,
>
> First, my sincere apologies for not being at the meeting and making you 
> stay at the office away from your family. Family is super important to me 
> and that time is very important and I am sorry I didn't respond to let you 
> know that I wouldn't be at the meeting. After the recent daylight saving 
> time change, I have a work meeting conflict every week now. I have updated 
> my availability for the rest of the meetings that I will not be able to 
> attend.
>
> Regards,
>
> Alex
>
> On Thu, Nov 19, 2020 at 1:37 AM Tim Jacomb  wrote:
>
>> The time also means I cant attend, so +1 for reviewing another time
>>
>> On Thu, 19 Nov 2020 at 08:18, Oleg Nenashev  wrote:
>>
>>> As discussed a few months ago, we will revise the meeting time once the 
>>> 2020 elections are over
>>> Since we have candidates from APAC, the meeting approach may require 
>>> significant changes, not just choosing the least worst timeslot for everyone
>>>
>>> On Thu, Nov 19, 2020 at 9:14 AM 'Olblak' via Jenkins Developers <
>>> jenkin...@googlegroups.com> wrote:
>>>
 Hi  Oleg,

 I am sorry to hear about that, that time is definitely really bad for 
 me as well.  

 On Wed, Nov 18, 2020, at 7:15 PM, Oleg Nenashev wrote:

 The meeting did not happen, because it was only me on the call. I 
 kindly ask board members and officers to reject the meeting invitations in 
 their calendars if they do not plan to attend. The timing for these 
 meeting 
 is quite bad for me, and it puts pressure on my family obligations. If I 
 know that nobody plans to join in advance, I won't be staying in the 
 office 
 for a few extra hours, and spend them with my family instead. Thanks for 
 understanding.

 On Wednesday, November 18, 2020 at 6:10:33 PM UTC+1 Oleg Nenashev wrote:

 Hi all,

 In 1 hour we will have a regular Jenkins Governance Meeting (starts at 
 6PM UTC). Everyone is welcome to join us and to participate in the 
 discussion. Meeting link: 
 https://zoom.us/j/91564716663?pwd=R3A2RDFGcU1wTVdoVTErYm1jNzVWdz09 

 Draft agenda:

- News!
- Jenkins elections status update
- LTS schedule update
- Google Summer of Code 2021
- Jenkins K8s Operator updates

 If you would like to add more topics, please suggest changes here 
 
 .

 Best regards,
 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/18072109-74c2-4cd6-9faf-15c04700826bn%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/4v01zfG5moM/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/d6468cf2-40c4-47b5-94a1-24f1e1e42b74%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-de...@googlegroups.com.
>>> To view 

Re: Config round trip failures in plugin unit tests?

[Mark Waite]

On Sun, Nov 29, 2020 at 1:11 AM Tim Jacomb  wrote:

> For the record commons-beanutils is provided by core at version 1.9.3 and
> it’s in the core bom.
>
> If it’s a transitive dep I would have thought the bom would have corrected
> the version, otherwise you can declare the dep without a version and scope
> provided and the bom should handle it
>
>
Thanks for the further insights.  I think I've understood the fundamental
mistake I made.

When I switched from requiring Jenkins 2.204.1 to require Jenkins 2.222.4
as the minimum Jenkins version, switched to use the 2.222.x bom, and *removed
the exclusion of commons-beanutils*, the GitStepTest.configRoundTrip
automated test consistently failed with a JavaScript error.

I could have continued using commons-validator 1.7 if I'd continued
excluding commons-beanutils as a dependency of commons-validator 1.7.  My
desire to remove exclusions got in the way.

The same issue would have been visible to me in Jenkins 2.204.1 if I had
removed the exclusion of commons-beanutils from the commons-validator
dependency.  The root mistake I made was removing the exclusion of
commons-beanutils.  Removing that exclusion caused commons-beanutils 1.9.4
to be included in the git.hpi file.  That inclusion broke the tests.  The
increase of minimum Jenkins version from 2.204.1 to 2.222.4 was not
involved in the issue.

The problem is resolved by https://github.com/jenkinsci/git-plugin/pull/1009
where the dependency on commons-validator is removed.  Validating user
input is important, but the checks that were being performed by
commons-validator are not so much more valuable that I should wrestle with
dependencies for them.

Thanks for the insights!
Mark Waite

-- 
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/CAO49JtHZT6v%2Bjqo6LZLfxSWn_p-%2B0pnhV0DMfQ-dt13q5FsiMA%40mail.gmail.com.

Re: Jenkins 3.x

[Tim Van Holder]

My $0.02:

Semantic Versioning is great for libraries; I'd certainly be in favour of
migrating to it for plugins. For core, not entirely certain.
In addition, you have PR labels that indicate when the changes require a
major or minor version bump. Release drafter takes that into account (or
should).
So the actual version bump can be applied when cutting the release, to
avoid issues where multiple PRs get merged and accidentally "overbump".

LTS releases are a bit of an issue in this regard. I'm not sure how they
would be best handled.
I suppose you could have SemVer for weeklies, then tack on a 4th number for
the LTSes (so if an LTS branch is cut from 4.2.7, the LTS is 4.2.7.1).
No longer SemVer then, but close enough (and my understanding is that LTS
updates are for fixes only, not new API).

It does mean that LTSes may go from 4.2.7.3 to 8.1.0.1 if there has been
especially active development in that quarter's weeklies.
I don't really see that as a problem, but some might.


Note: I have nothing against a .MM[.1] schema either; it doesn't
communicate anything about the amount/impact of changes it includes, but
that's what release and upgrade notes are for.


On Sat, 28 Nov 2020 at 00:06, Richard Bywater  wrote:

> Just keeping an eye on the thread it seems to me that, before any decision
> should be made about whether a bump to 3.x was done, a clear policy on
> versioning really needs to be introduced on what constitutes a major
> version bump so that it's clear that if xyz is implemented then that will
> be done then we would need another version bump in the future. Otherwise we
> run the risk of having this discussion time and time again.
>
> I think Jenkins 2.x made sense as it was quite a paradigm shift in the
> usage of Jenkins not (as far as I can tell or remember - happy to be
> corrected) anything to do with breakages or incompatibilities. It really
> announced that pipelines were the way of the future for Jenkins and
> therefore warranted a bump.
>
> I'm not sure this change really has the same thing going for it as (again
> correct me if I'm wrong) we've had previous changes that have broken
> plugins to require them to be updated with fixes or changes before it could
> be upgraded?
>
> Personally I dont think closed source plugins breaking with the change
> should be a major concern as long as we've clearly announced to plugin
> owners that in version xyz your plugin will need a change as they should
> really be keeping an eye on required changes as the majority I'd say are
> getting paid money by customers for the service.
>
> Just my 2 cents :)
>
> Richard
>
> On Sat, 28 Nov 2020, 11:19 AM Oleg Nenashev, 
> wrote:
>
>> There is clearly no consensus here, and IMHO we need to wait until the
>> new Event officer takes the role. I doubt we can make a final decision by
>> the next weekly release on Tuesday, so my suggestion is to keep discussing
>> it and to also add it to the governance meeting agenda on Dec 02.
>>
>> On Friday, November 27, 2020 at 10:46:21 PM UTC+1 Daniel Beck wrote:
>>
>>>
>>>
>>> > On 27. Nov 2020, at 18:26, James Nord  wrote:
>>> >
>>> > Could we maybe keep the discussion here to just a 3.x bump as we are
>>> more likely to reach a consensus?
>>>
>>> As a technical/compatibility indicator, 3.0 makes little sense because
>>> it's late. None of the related documentation would even say "from Jenkins
>>> 3.0" (if it did, it would be wrong). Plus there's no commitment to semver
>>> in the future, making this not even useful from an admin POV as an
>>> indicator that we're going to apply semver in the future. It might even be
>>> actively bad to create an expectation that incompatible changes bump the
>>> major version the next time we integrate a big change. People who read the
>>> documentation before updating will see huge warning signs either way, and
>>> can make an informed decision. People who don't will experience the same
>>> pain either way.
>>>
>>> As a marketing/"there's big new stuff" indicator, I don't think there's
>>> enough big new stuff here from a regular user POV. Ideally XStream and
>>> Spring work without a ton of problems (and do we really want to highlight
>>> how bad things were until now?), and tables to div is nice but not on the
>>> scale I would expect as a user to justify the major version bump. All these
>>> changes are mostly internal, with some nice but overall modest visual
>>> updates to the configuration forms. Not to mention we'd need a solid plan
>>> for announcements, documentation, etc. -- a lot of that nature was done for
>>> Jenkins 2.
>>>
>>> To me, this idea comes at least a month late, probably two, and going
>>> for it unprepared will just cause problems, while not actually
>>> accomplishing much.
>>>
>>> --
>> 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 

Re: Config round trip failures in plugin unit tests?

[Tim Jacomb]

For the record commons-beanutils is provided by core at version 1.9.3 and
it’s in the core bom.

If it’s a transitive dep I would have thought the bom would have corrected
the version, otherwise you can declare the dep without a version and scope
provided and the bom should handle it

On Sat, 28 Nov 2020 at 21:55, Daniel Beck  wrote:

>
>
> > On 28. Nov 2020, at 20:58, Mark Waite  wrote:
> >
> > I assume  commons-beanutils 1.9.4 (released in August 2019) is not being
> used by anyone else in Jenkins core or plugins.
>
> commons-beanutils 1.9.4 is known to core maintainers to not be useable in
> Jenkins. We've now had two PRs for that update, both failed.
>
> --
> 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/2A8105CE-CBEE-4886-8276-CC4D50528645%40beckweb.net
> .
>

-- 
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-3BicjksTx7xMrB%2BVmHhrBDr6pF2OU-XyK%3DxgDSh7NxueSew%40mail.gmail.com.