Re: Adopt oic-auth-plugin

[Rick]

Hi Michael,

Would mind me to be another maintainer?

Best,

On Tue, Aug 27, 2019 at 7:57 AM Rick  wrote:

> Hi Michael,
>
> It's totally reasonable. I'm the maintainer of serval plugins. Sometimes,
> I just don't have enough time out maintain them like you.
>
> Best,
>
> On Mon, Aug 26, 2019 at 10:09 PM Michael Bischoff <
> michael.bisch...@controplex.nl> wrote:
>
>> Hello Rick,
>>
>> Yeah it would be good to have at least another maintainer for the plugin.
>> I actually take some days off a couple of times a year to run trough things
>> and actually solve and close issues.
>> I've been a bit skittish with regards to replying to issues being opened
>> as I haven't found any time to sit down and resolve things.
>>
>> Perhaps we should talk direction and expectations at some point?
>>
>> Best regards,
>>
>> Michael
>>
>> On Sun, 25 Aug 2019 at 03:43, Rick  wrote:
>>
>>> Hi Gavin,
>>>
>>> Thanks for your suggestion. The issue
>>>  was created
>>> now.
>>>
>>> On Sun, Aug 25, 2019 at 9:36 AM 'Gavin Mogan' via Jenkins Developers <
>>> jenkinsci-dev@googlegroups.com> wrote:
>>>
 As far as I know, you need to make a best attempt to contact the
 current maintainer before the timeout happens.

 So I'm adding m.bisch...@controplex.com as thats what is listed in the
 pom file.  (Which i suspect will bounce because
 https://github.com/mjmbischoff/nexus-blobstore-swift/issues/2#issuecomment-507164722
 says they just switched jobs)

 @Rick can you also make a github issue on oic-auth-plugin
  asking for
 maintainership and tagging @mjmbischoff in a comment?

 Gavin

 On Sat, Aug 24, 2019 at 6:08 PM Marky Jackson <
 marky.r.jack...@gmail.com> wrote:

> +1 from me
>
> On Aug 24, 2019, at 6:06 PM, Rick  wrote:
>
> Hi team,
>
> I'd like to adopt oic-auth-plugin
> . This plugin looks
> like lack of maintaining since Feb.
>
> I already started a thread here
> 
> to waiting for the author's response.
>
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
>
> --
> 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/CAMM7nTFgo1H0kOqS0JXsdaXcw%3DDzOV4Zjux8Yi6CObzW8Qpn0Q%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/0FB3F3E4-B877-4923-879C-869FA2F70758%40gmail.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/CAG%3D_DuutWdzVyQrOne3om-wiKN%3DFjG9rxtjfTY8iA%3DVE1fQnxA%40mail.gmail.com
 
 .

>>>
>>>
>>> --
>>> Zhao Xiaojie (Rick)
>>> Blog: https://github.com/LinuxSuRen
>>> Twitter: https://twitter.com/suren69811254
>>>
>>>
>
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
>

-- 
Zhao Xiaojie (Rick)
Blog: https://github.com/LinuxSuRen
Twitter: https://twitter.com/suren69811254

-- 
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/CAMM7nTHCYCpgC1CjprvxNsD6VkmgXdg8rdbVi%2BWVrLETgc774w%40mail.gmail.com.

Re: Unable to configure Fork Change Request Trait using Job DSL

[Joseph P]

Thanks for creating a patch for this 殺

/Joseph

On Monday, August 19, 2019 at 9:17:45 PM UTC+2, Daniel Spilker wrote:
>
> Hi Parichay,
>
> I meant changing the constructor to
>
> public ForkMergeRequestDiscoveryTrait(int strategyId, SCMHeadAuthority 
> trust) {
>
> until Structs plugin supports parameters with parameterized type. 
>
> I opened a pull request to add some support for parameterized types to 
> Structs plugin:
> https://github.com/jenkinsci/structs-plugin/pull/52
>
> I tested the fix with Job DSL. It will enable the DSL syntax from my 
> previous post.
>
> Regards,
> Daniel
>
>
> On Mon, Aug 19, 2019 at 5:39 PM Parichay Barpanda  > wrote:
>
>> Thanks Daniel. But I didn't understand by what you meant "remove the type 
>> parameters". I was able to configure the trait using `configure` block. 
>> https://gist.github.com/baymac/f1a2249a0ec7b999c057056937e752a6 
>>
>> On Saturday, August 17, 2019 at 5:09:03 PM UTC+5:30, Daniel Spilker wrote:
>>>
>>> Hi Parichay,
>>>
>>> the Job DSL script would be this:
>>>
>>> organizationFolder('example') {
>>>   organizations {
>>> gitLabSCMNavigator {
>>>   projectOwner('test')
>>>   traits {
>>> gitLabForkDiscovery {
>>>   strategyId(42)
>>>   trust {
>>> gitLabTrustNobody()
>>>   }
>>> }
>>>   }
>>> }
>>>   }
>>> }
>>>
>>> But the script will fail. The problem is caused by the "trust" 
>>> constructor parameter of ForkMergeRequestDiscoveryTrait. Job DSL uses 
>>> the Structs plugin for introspection of Describables. Unfortunately Structs 
>>> does not handle parameter types with generics except for sub classes of 
>>> java.util.Collection. So the trait will not be shown in the API viewer.
>>>
>>> To check if a class is supported by Structs (and Job DSL), run the 
>>> following in the Jenkins script console:
>>>
>>> org.jenkinsci.plugins.structs.describable.DescribableModel.of(io.jenkins.plugins.gitlabbranchsource.ForkMergeRequestDiscoveryTrait)
>>>
>>> The result will be
>>>
>>> ForkMergeRequestDiscoveryTrait(strategyId: int, trust: 
>>> java.lang.UnsupportedOperationException: do not know how to categorize 
>>> attributes of type jenkins.scm.api.trait.SCMHeadAuthority>> io.jenkins.plugins.gitlabbranchsource.GitLabSCMSourceRequest, ? extends 
>>> jenkins.scm.api.mixin.ChangeRequestSCMHead2, ? extends 
>>> jenkins.scm.api.SCMRevision>)
>>>
>>> As a workaround, you can remove the type parameters from the "trust" 
>>> constructor parameter. 
>>>
>>> @Jesse: would it be feasible to fallback to the raw type when a 
>>> parameterized type is detected?
>>>
>>> https://github.com/jenkinsci/structs-plugin/blob/structs-parent-1.20/plugin/src/main/java/org/jenkinsci/plugins/structs/describable/ParameterType.java#L104
>>>
>>> Regards,
>>> Daniel
>>>
>>>
>>> On Fri, Aug 16, 2019 at 3:11 PM Parichay Barpanda  
>>> wrote:
>>>
 Hi all,

 I am trying to configure GitLab Branch Source Plugin organizational 
 folder using Job DSL. But unfortunately job dsl api viewer doesn't detect 
 Fork 
 Merge Request Trait 
 .
  
 All the detected traits in Job dsl api viewer takes either 
 int/boolean/string values. But in Fork Merge Request Trait the trust field 
 takes an SCMHeadAuthority object. How does one configure Job DSL with fork 
 `change request` trait for any of the branch source plugin?

 Can someone help me with figuring out what is wrong here. I have the 
 following cases:

 1. Job DSL doesn't support Fork Merge Request Trait.

 2. There is something wrong with the impl of Fork Merge Request Trait.

 3. Our Job DSL configuration is incorrect (note unable to configure 
 fork merge request in this configuration):

 organizationFolder(name) {
   organizations {
 displayName(config.displayName)
 description(orgDescription)
 gitLabSCMNavigator {
   projectOwner(config.group)
   credentialsId('gitlab_ssh_key')
   serverName('git.3shape.local')
   traits {
 subGroupProjectDiscoveryTrait() // discover projects 
 inside subgroups
 gitLabBranchDiscovery {
   strategyId(3) // discover all branches
 }
 originMergeRequestDiscoveryTrait {
   strategyId(1) // discover MRs and merge them with target 
 branch
 }
 gitLabTagDiscovery() // discover tags
 gitLFSPullTrait()
   }
 }
   }
   orphanedItemStrategy {
 discardOldItems {
   daysToKeep(7)
   numToKeep(10)
 }
   }
   if (!isSandbox()) {
 triggers {
  

Re: Preparing your modules/library/plugin to be consumed by dependabot

[Joseph P]

Hi Gavin, we actually made that change in JCasC to prepare 
for https://github.com/jenkins-infra/plugin-site-api/pull/54
Good that dependabot is something you can depend on 

Original PR 
https://github.com/jenkinsci/configuration-as-code-plugin/pull/1004

On Tuesday, August 27, 2019 at 6:50:38 PM UTC+2, Gavin Mogan wrote:
>
> Hey Ya'll,
>
> tl;dr - Make sure project > scm > url is set to github, (example 
> https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/pom.xml#L41
> )
>
> ---
>
> I thought I'd share my limited findings with all of your. A couple weeks 
> ago I contacted dependabot support to try and find out why some javascript 
> modules had changelogs/release notes mentioned. I got a bunch of good 
> responses back, and nudged them to document this info publicly.
>
> But for now, I share what I learned.
>
> Dependabot has a lot of open source code, including how it processes 
> module metadata.
>
>
> https://github.com/dependabot/dependabot-core/blob/e654f214a932672d8ac0ea428ef9d672ac5bba33/maven/lib/dependabot/maven/metadata_finder.rb#L52
>
> It loops through a bunch of properties inside the maven pom file, project 
> > url (which should point at wiki/plugins site for us), project > scm > url 
> (which right place to set it), and lastly project > issueManagement > url 
> (which probably defaults to jira)
>
> When that url is set right, dependabot knows where to pull information 
> from. See https://github.com/jenkinsci/ci.jenkins.io-runner/pull/192 as a 
> good example.
>
> It'll list the commits between tags. Release Notes if you use github 
> releases (release drafter makes that easy) and Changelog if it can find a 
> changelog file in the repo. I can go into more details about this if people 
> want.
>
> *But I strongly recommend at least setting up project > scm > url, and 
> either a changelog file, or preferably release notes for releases.*
>
> That'll make other plugin authors know if its worth upgrading/what 
> potentially might break when getting a dependabot PR.
>
> Thanks,
> Gavin
>
>

-- 
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/73df2ca3-23a2-4ec2-9af5-a34f9b1291e0%40googlegroups.com.

Re: Hosting process

['Gavin Mogan' via Jenkins Developers]

> Which would be a downside I think.

Oh I thought that was the intention

Yea for sure a downside

On Wed, Aug 28, 2019 at 11:56 AM Jesse Glick  wrote:

> On Wed, Aug 28, 2019 at 12:31 PM 'Gavin Mogan' via Jenkins Developers
>  wrote:
> > That would break the fork linkage
>
> Which would be a downside I think. Also the current method forces you
> to remember to delete your own account’s clone so the @jenkinsci one
> does not appear as a fork of it.
>
> Also you would lose any existing issues, PRs, etc.
>
> The repository transfer operation seems like the most intuitive and
> least problematic approach.
>
> --
> 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/CANfRfr1_d16DVnis%3DQRpZa5R%3D_VXaw94pr%2BCLyHL%2BuBz%3DF64bw%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/CAG%3D_DutDuG5o9bBrGwCX3-JvOkqzocb%3DqEFk8c%2BVwqN4kxvLVQ%40mail.gmail.com.

Re: Request for admin permissions to ec2-plugin repo

[Marky Jackson]

This is my bad, they did that and I told them to do this

> On Aug 28, 2019, at 11:56 AM, Jesse Glick  wrote:
> 
> On Wed, Aug 28, 2019 at 1:47 PM Raihaan Shouhell
>  wrote:
>> Could I be granted the appropriate permissions?
> 
> You can skip posting to the dev list for this sort of thing, and just
> open a ticket in the `INFRA` project / `github` component.
> 
> -- 
> 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/CANfRfr1LyVoBWs%3D0pOMP%3D-oZOXt3tgNV0faJ8C-7gp9YBWq9TQ%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/BD3E65E8-F331-495E-A092-485448EE5192%40gmail.com.

Re: Request for admin permissions to ec2-plugin repo

[Jesse Glick]

On Wed, Aug 28, 2019 at 1:47 PM Raihaan Shouhell
 wrote:
> Could I be granted the appropriate permissions?

You can skip posting to the dev list for this sort of thing, and just
open a ticket in the `INFRA` project / `github` component.

-- 
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/CANfRfr1LyVoBWs%3D0pOMP%3D-oZOXt3tgNV0faJ8C-7gp9YBWq9TQ%40mail.gmail.com.

Re: Hosting process

[Jesse Glick]

On Wed, Aug 28, 2019 at 12:31 PM 'Gavin Mogan' via Jenkins Developers
 wrote:
> That would break the fork linkage

Which would be a downside I think. Also the current method forces you
to remember to delete your own account’s clone so the @jenkinsci one
does not appear as a fork of it.

Also you would lose any existing issues, PRs, etc.

The repository transfer operation seems like the most intuitive and
least problematic approach.

-- 
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/CANfRfr1_d16DVnis%3DQRpZa5R%3D_VXaw94pr%2BCLyHL%2BuBz%3DF64bw%40mail.gmail.com.

Re: Replace authorize-project-plugin

[René Scheibe]

Hi everybody,

Since Jenkins LTS 2.176.1 (https://jenkins.io/doc/upgrade-guide/2.176/) 
which includes https://issues.jenkins-ci.org/browse/JENKINS-24513 there is 
an administrative monitor in place. It recommends to install the 
authorize-project plugin.

Having a look at the usage chart at 
https://plugins.jenkins.io/authorize-project also shows that the usage 
started to increase heavily starting 2019.

I guess it would be a good idea to add some information about the 
limitations on the plugin page.

-- 
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/ad500262-4391-4be2-acf7-8e0774e74c61%40googlegroups.com.

Re: Request for admin permissions to ec2-plugin repo

[Marky Jackson]

To add to this, Raihaan is already the maintainer of this plugin and has rights 
to the repo but also needs to be added to the admin group for this repository 
so release-drafter and dependabot can be added.

> On Aug 28, 2019, at 8:36 AM, Raihaan Shouhell  
> wrote:
> 
> Hi all,
> 
> I'd like to enable release-drafter and dependabot for ec2-plugin's repository 
> but do not have enough permissions on it.
> Could I be granted the appropriate permissions?
> 
> My github id is res0nance
> 
> Cheers,
> Raihaan
> 
> -- 
> 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/255fc5a2-7d93-43aa-8119-4ac7928631b3%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/E35F501B-AF4A-443B-8E10-9E8E027BCED9%40gmail.com.

Request for admin permissions to ec2-plugin repo

[Raihaan Shouhell]

Hi all,

I'd like to enable release-drafter and dependabot for ec2-plugin's 
repository but do not have enough permissions on it.
Could I be granted the appropriate permissions?

My github id is res0nance

Cheers,
Raihaan

-- 
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/255fc5a2-7d93-43aa-8119-4ac7928631b3%40googlegroups.com.

Re: Hosting process

[Slide]

On Wed, Aug 28, 2019 at 9:31 AM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Why transfer it at all? Why not clone, create the new repo, then push.
>
> That would break the fork linkage, and be less complicated.
>
> Probably a little slower but doesn't need to be realtime speeds
>

That is another option. That would require the ircbot that completes the
hosting request to have git capabilities in its container to clone the
originating repo and push to the newly created repo. That is not
unreasonable, it may be more complex to make sure all steps work all of the
time.



>
> On Wed., Aug. 28, 2019, 9:03 a.m. Slide,  wrote:
>
>>
>> On Wed, Aug 28, 2019 at 8:59 AM Oleg Nenashev 
>> wrote:
>>
>>>  the requester would initiate a repository transfer request on Github

>>>
>>> Note that it used to require some additional automation logic, because a
>>> contributor cannot just move a project to jenkinsci.
>>> It has to happen through an intermediate organization like
>>> https://github.com/jenkinsci-transfer we use now.
>>>
>>> I need to test whether there is a transfer request feature in GitHub and
>>> whether we can automate the bot somehow. If so, this is perfect
>>>
>>
>>
>> Correct, the transfer request is initiated by someone with access on the
>> origin repository side, but the request has to be authorized by the
>> receiving organization. The automation of the transfer request acceptance
>> is definitely something that needs to be figured out.
>>
>>
>>
>>>
>>>
>>> On Wednesday, August 28, 2019 at 5:16:04 PM UTC+2, Matt Sicker wrote:

 Sounds like a good idea.

 On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers
  wrote:
 >
 > +1
 > I like the idea of not having to contact support to break the link
 >
 >
 > On Tue, Aug 27, 2019 at 10:01 AM Slide  wrote:
 >>
 >> Based on some feedback from various people during plugin hosting
 requests, our current method of forking and renaming repositories is not as
 desirable as one might hope. I am thinking of creating a JEP to change the
 process, but wanted to solicit some feedback before I do so. I would like
 to propose that the process be changed as follows:
 >>
 >> 1) Person/Org submits request to the HOSTING project, but the New
 Repository Name field is removed.
 >> 2) The normal checks occur, however, now the originating repository
 name must follow the rules that we normally used for New Repository Name
 (e.g., if a plugin it must end in -plugin, no camelcase, etc).
 >> 3) Once the plugin has has completed the review process as it does
 now (automated checker and human review) the requester would initiate a
 repository transfer request on Github
 >> 4) Once the transfer request has been submitted, the ircbot would be
 updated such that the "host" command would accept the transfer and setup
 the teams on the repository to complete the transfer.
 >>
 >> This would remove the need for users to break the relationship
 between the originating repository and the jenkinsci repository (which
 would become the canonical repository).
 >>
 >> Please let me know your thoughts on this process change idea. If it
 has good feedback, I'll submit a JEP to document the process.
 >>
 >> --
 >> 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 jenkin...@googlegroups.com.
 >> To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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 jenkin...@googlegroups.com.
 > To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.




 --
 Matt Sicker
 Senior Software Engineer, CloudBees

>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/a9f09d9d-7c03-4610-993d-c5a448134192%40googlegroups.com
>>> 
>>> .
>>>
>>
>>
>> --
>> Website: http://earl-of-code.com
>>
>> 

Re: Hosting process

['Gavin Mogan' via Jenkins Developers]

Why transfer it at all? Why not clone, create the new repo, then push.

That would break the fork linkage, and be less complicated.

Probably a little slower but doesn't need to be realtime speeds

On Wed., Aug. 28, 2019, 9:03 a.m. Slide,  wrote:

>
> On Wed, Aug 28, 2019 at 8:59 AM Oleg Nenashev 
> wrote:
>
>>  the requester would initiate a repository transfer request on Github
>>>
>>
>> Note that it used to require some additional automation logic, because a
>> contributor cannot just move a project to jenkinsci.
>> It has to happen through an intermediate organization like
>> https://github.com/jenkinsci-transfer we use now.
>>
>> I need to test whether there is a transfer request feature in GitHub and
>> whether we can automate the bot somehow. If so, this is perfect
>>
>
>
> Correct, the transfer request is initiated by someone with access on the
> origin repository side, but the request has to be authorized by the
> receiving organization. The automation of the transfer request acceptance
> is definitely something that needs to be figured out.
>
>
>
>>
>>
>> On Wednesday, August 28, 2019 at 5:16:04 PM UTC+2, Matt Sicker wrote:
>>>
>>> Sounds like a good idea.
>>>
>>> On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers
>>>  wrote:
>>> >
>>> > +1
>>> > I like the idea of not having to contact support to break the link
>>> >
>>> >
>>> > On Tue, Aug 27, 2019 at 10:01 AM Slide  wrote:
>>> >>
>>> >> Based on some feedback from various people during plugin hosting
>>> requests, our current method of forking and renaming repositories is not as
>>> desirable as one might hope. I am thinking of creating a JEP to change the
>>> process, but wanted to solicit some feedback before I do so. I would like
>>> to propose that the process be changed as follows:
>>> >>
>>> >> 1) Person/Org submits request to the HOSTING project, but the New
>>> Repository Name field is removed.
>>> >> 2) The normal checks occur, however, now the originating repository
>>> name must follow the rules that we normally used for New Repository Name
>>> (e.g., if a plugin it must end in -plugin, no camelcase, etc).
>>> >> 3) Once the plugin has has completed the review process as it does
>>> now (automated checker and human review) the requester would initiate a
>>> repository transfer request on Github
>>> >> 4) Once the transfer request has been submitted, the ircbot would be
>>> updated such that the "host" command would accept the transfer and setup
>>> the teams on the repository to complete the transfer.
>>> >>
>>> >> This would remove the need for users to break the relationship
>>> between the originating repository and the jenkinsci repository (which
>>> would become the canonical repository).
>>> >>
>>> >> Please let me know your thoughts on this process change idea. If it
>>> has good feedback, I'll submit a JEP to document the process.
>>> >>
>>> >> --
>>> >> 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 jenkin...@googlegroups.com.
>>> >> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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 jenkin...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.
>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker
>>> Senior Software Engineer, CloudBees
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/a9f09d9d-7c03-4610-993d-c5a448134192%40googlegroups.com
>> 
>> .
>>
>
>
> --
> 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/CAPiUgVea1oZG7yWsAwjbEUyz1HOWMfs8b0AodnVvbf_m_w3hwQ%40mail.gmail.com
> 

Re: Impact of BOM on plugin versions

[Matt Sicker]

Ok, thanks for the clarification. And I assumed it based on all the
Maven knowledge you have. ;)

On Wed, Aug 28, 2019 at 10:43 AM Jesse Glick  wrote:
>
> On Wed, Aug 28, 2019 at 11:15 AM Matt Sicker  wrote:
> > I thought you were already on the Maven PMC.
>
> Perhaps you were thinking of Stephen.
>
> > are you suggesting that I shouldn't use the bom in credentials?
>
> No, I was just linking to an IT demonstrating that—so far as I can
> tell—it is safe to consume an older release of a BOM in a component
> which is then in turn included in a newer release of the same BOM.
>
> --
> 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/CANfRfr3aPg%2BF6-Zd2K%2BpcqSFcQTNA8uh2a%3D4jTfYv-MwMY_TRA%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

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

Re: Hosting process

[Slide]

On Wed, Aug 28, 2019 at 8:59 AM Oleg Nenashev 
wrote:

>  the requester would initiate a repository transfer request on Github
>>
>
> Note that it used to require some additional automation logic, because a
> contributor cannot just move a project to jenkinsci.
> It has to happen through an intermediate organization like
> https://github.com/jenkinsci-transfer we use now.
>
> I need to test whether there is a transfer request feature in GitHub and
> whether we can automate the bot somehow. If so, this is perfect
>


Correct, the transfer request is initiated by someone with access on the
origin repository side, but the request has to be authorized by the
receiving organization. The automation of the transfer request acceptance
is definitely something that needs to be figured out.



>
>
> On Wednesday, August 28, 2019 at 5:16:04 PM UTC+2, Matt Sicker wrote:
>>
>> Sounds like a good idea.
>>
>> On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers
>>  wrote:
>> >
>> > +1
>> > I like the idea of not having to contact support to break the link
>> >
>> >
>> > On Tue, Aug 27, 2019 at 10:01 AM Slide  wrote:
>> >>
>> >> Based on some feedback from various people during plugin hosting
>> requests, our current method of forking and renaming repositories is not as
>> desirable as one might hope. I am thinking of creating a JEP to change the
>> process, but wanted to solicit some feedback before I do so. I would like
>> to propose that the process be changed as follows:
>> >>
>> >> 1) Person/Org submits request to the HOSTING project, but the New
>> Repository Name field is removed.
>> >> 2) The normal checks occur, however, now the originating repository
>> name must follow the rules that we normally used for New Repository Name
>> (e.g., if a plugin it must end in -plugin, no camelcase, etc).
>> >> 3) Once the plugin has has completed the review process as it does now
>> (automated checker and human review) the requester would initiate a
>> repository transfer request on Github
>> >> 4) Once the transfer request has been submitted, the ircbot would be
>> updated such that the "host" command would accept the transfer and setup
>> the teams on the repository to complete the transfer.
>> >>
>> >> This would remove the need for users to break the relationship between
>> the originating repository and the jenkinsci repository (which would become
>> the canonical repository).
>> >>
>> >> Please let me know your thoughts on this process change idea. If it
>> has good feedback, I'll submit a JEP to document the process.
>> >>
>> >> --
>> >> 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 jenkin...@googlegroups.com.
>> >> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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 jenkin...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.
>>
>>
>>
>>
>> --
>> Matt Sicker
>> Senior Software Engineer, CloudBees
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a9f09d9d-7c03-4610-993d-c5a448134192%40googlegroups.com
> 
> .
>


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

Re: Hosting process

[Oleg Nenashev]

>
>  the requester would initiate a repository transfer request on Github
>

Note that it used to require some additional automation logic, because a 
contributor cannot just move a project to jenkinsci.
It has to happen through an intermediate organization like 
https://github.com/jenkinsci-transfer we use now.

I need to test whether there is a transfer request feature in GitHub and 
whether we can automate the bot somehow. If so, this is perfect

 

On Wednesday, August 28, 2019 at 5:16:04 PM UTC+2, Matt Sicker wrote:
>
> Sounds like a good idea. 
>
> On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers 
> > wrote: 
> > 
> > +1 
> > I like the idea of not having to contact support to break the link 
> > 
> > 
> > On Tue, Aug 27, 2019 at 10:01 AM Slide > 
> wrote: 
> >> 
> >> Based on some feedback from various people during plugin hosting 
> requests, our current method of forking and renaming repositories is not as 
> desirable as one might hope. I am thinking of creating a JEP to change the 
> process, but wanted to solicit some feedback before I do so. I would like 
> to propose that the process be changed as follows: 
> >> 
> >> 1) Person/Org submits request to the HOSTING project, but the New 
> Repository Name field is removed. 
> >> 2) The normal checks occur, however, now the originating repository 
> name must follow the rules that we normally used for New Repository Name 
> (e.g., if a plugin it must end in -plugin, no camelcase, etc). 
> >> 3) Once the plugin has has completed the review process as it does now 
> (automated checker and human review) the requester would initiate a 
> repository transfer request on Github 
> >> 4) Once the transfer request has been submitted, the ircbot would be 
> updated such that the "host" command would accept the transfer and setup 
> the teams on the repository to complete the transfer. 
> >> 
> >> This would remove the need for users to break the relationship between 
> the originating repository and the jenkinsci repository (which would become 
> the canonical repository). 
> >> 
> >> Please let me know your thoughts on this process change idea. If it has 
> good feedback, I'll submit a JEP to document the process. 
> >> 
> >> -- 
> >> 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 jenkin...@googlegroups.com . 
> >> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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 jenkin...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.
>  
>
>
>
>
> -- 
> Matt Sicker 
> Senior Software Engineer, CloudBees 
>

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

Re: Impact of BOM on plugin versions

[Jesse Glick]

On Wed, Aug 28, 2019 at 11:15 AM Matt Sicker  wrote:
> I thought you were already on the Maven PMC.

Perhaps you were thinking of Stephen.

> are you suggesting that I shouldn't use the bom in credentials?

No, I was just linking to an IT demonstrating that—so far as I can
tell—it is safe to consume an older release of a BOM in a component
which is then in turn included in a newer release of the same BOM.

-- 
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/CANfRfr3aPg%2BF6-Zd2K%2BpcqSFcQTNA8uh2a%3D4jTfYv-MwMY_TRA%40mail.gmail.com.

Re: Hosting process

[Matt Sicker]

Sounds like a good idea.

On Tue, Aug 27, 2019 at 12:03 PM 'Gavin Mogan' via Jenkins Developers
 wrote:
>
> +1
> I like the idea of not having to contact support to break the link
>
>
> On Tue, Aug 27, 2019 at 10:01 AM Slide  wrote:
>>
>> Based on some feedback from various people during plugin hosting requests, 
>> our current method of forking and renaming repositories is not as desirable 
>> as one might hope. I am thinking of creating a JEP to change the process, 
>> but wanted to solicit some feedback before I do so. I would like to propose 
>> that the process be changed as follows:
>>
>> 1) Person/Org submits request to the HOSTING project, but the New Repository 
>> Name field is removed.
>> 2) The normal checks occur, however, now the originating repository name 
>> must follow the rules that we normally used for New Repository Name (e.g., 
>> if a plugin it must end in -plugin, no camelcase, etc).
>> 3) Once the plugin has has completed the review process as it does now 
>> (automated checker and human review) the requester would initiate a 
>> repository transfer request on Github
>> 4) Once the transfer request has been submitted, the ircbot would be updated 
>> such that the "host" command would accept the transfer and setup the teams 
>> on the repository to complete the transfer.
>>
>> This would remove the need for users to break the relationship between the 
>> originating repository and the jenkinsci repository (which would become the 
>> canonical repository).
>>
>> Please let me know your thoughts on this process change idea. If it has good 
>> feedback, I'll submit a JEP to document the process.
>>
>> --
>> 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/CAPiUgVdKJLWzcuAAVnmZRwwLvrZyRSC_wYdizp-TYbEMyh-ziQ%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/CAG%3D_DuuGgswR6B%2BC930Sh%3Dm-yzU%3D%3DrD3FA%3DNXh9YXDAXrQaV5Q%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

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

Re: Impact of BOM on plugin versions

[Matt Sicker]

And here I thought you were already on the Maven PMC. Perhaps you
could try reminding them on the dev lists?

Also, are you suggesting that I shouldn't use the bom in credentials?
Or is that issue resolved?

On Tue, Aug 27, 2019 at 11:07 AM Jesse Glick  wrote:
>
> On Tue, Aug 27, 2019 at 11:09 AM Matt Sicker  wrote:
> > I've made two new releases for credentials since then (2.2.1 and
> > 2.3.0, the latter of which was released just yesterday).
>
> …which may have broken something, by the way:
>
> https://github.com/jenkinsci/bom/pull/77
>
> > it's somewhat amusing
> > that it imports a dependencyManagement for itself, though it doesn't
> > appear to adversely affect the build at all.
>
> Still waiting for
>
> https://github.com/apache/maven-integration-testing/pull/25
>
> :-(
>
> --
> 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/CANfRfr1cDFNCj0GhfWdAJK3TXTTZRvyvmnZW7FX%3DBoR4GwEBTg%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

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

Re: SwaggerHub for Jenkins

[Oleg Nenashev]

Just to bump this thread, I would say that it would be great to have REST 
API specs hosted in a centralized ways, similar to plugin Javadocs 
. Looks like SwaggerHub offers a pretty 
good user experience, so why not? 

Some notes:

   - We could also make Swagger documentation upload a part of the plugin 
   continuous delivery flow once it is ready
   - Same, we could add links to REST API specs to plugins.jenkins.io once 
   there is a critical mass of plugins using such approach
   - The story would be really interesting if combined with the automatic 
   Swagger spec generation for Jenkins plugins (GSoC 2019 project idea 
   

   )

Best regards,
Oleg

On Wednesday, August 14, 2019 at 7:09:47 PM UTC+2, Abhyudaya Sharma wrote:
>
> Hi everyone!
>
> I would like to suggest having a Jenkins organization account on 
> SwaggerHub. For the new Folder Auth plugin 
> , I have created a 
> Swagger YAML specification for the plugin's REST APIs. You can check it out 
> here . 
> Having such a specification would help potential users find the APIs (and 
> documentation) without needing to dig deep into the codebase. Also, 
> SwaggerHub can generate stubs in multiple languages for users to easily 
> interact with these APIs. Currently, the specification for the Folder Auth 
> plugin is hosted on my personal account. It would be great to have a 
> Jenkins organization account like on GitHub and have a common store for 
> APIs of all plugins.
>
> Thanks
> Abhyudaya Sharma
> GitHub: AbhyudayaSharma
>

-- 
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/6764a04d-3d4a-45c2-80fe-1d186fcc0257%40googlegroups.com.

Re: Next LTS line selection open. Due 2019-08-27

[Mark Waite]

+1 from me to choose 2.190 as the baseline.

On Wednesday, August 28, 2019 at 7:39:31 AM UTC-4, Oleg Nenashev wrote:
>
> Great to see the fix!  https://github.com/jenkinsci/jenkins/pull/4176 can 
> be trivially backported, so I think we can go ahead with 2.190 as a 
> baseline.
>
> BR, Oleg
>
>
> On Wed, Aug 28, 2019 at 12:54 PM Mark Waite wrote:
>
>>
>>
>> On Tuesday, August 27, 2019 at 6:00:13 AM UTC-4, Oleg Nenashev wrote:
>>>
>>> For me 2.187 is a default pick. If somebody investigates  JENKINS-58912 
>>> 
>>>  / JENKINS-58938  and 
>>> clarifies impact/possibility of a fix for .1, then I am fine with 190. 
>>> Cannot commit to investigate it unfortunately
>>>
>>> There are some reasons to want 2.190. Apart from emoji support for job 
>>> names (yey!) there are some more meaningful changes like plugin 
>>> installation parallelization for Setup Wizard (Jenkins Startup Experience), 
>>> security hardening, install-plugin fixes, and other changes which could 
>>> help LTS users.
>>>
>>>
>> Gabriel Lavoie has submitted a pull request to fix those two issues.  The 
>> pull request is at https://github.com/jenkinsci/jenkins/pull/4176 and is 
>> related to the slow trigger monitor that was first released in 2.189.
>>
>> I haven't yet been able to interactively verify the problem myself, but 
>> am thrilled that Gabriel was able to do so and that a pull request has been 
>> submitted.
>>
>> That change leads me towards favoring 2.187, before that admin monitor 
>> was added.  I could be persuaded otherwise (especially considering the 
>> security fix that was announced for today), assuming we also have a fix for 
>> the remoting issue that was reported as 
>> https://issues.jenkins-ci.org/browse/JENKINS-59094
>>
>> Mark Waite
>>  
>>
>>> On Tuesday, August 27, 2019 at 11:50:34 AM UTC+2, ogondza wrote:

 So I guess that eliminates 2.191 as a choice for LTS. I do not feel 
 that 
 strong choosing between 2.190 and 2.187, and it appears Oleg and Mark 
 leans that way. 

 Any other inputs? 

 On 27/08/2019 11.15, Oleg Nenashev wrote: 
 > There is a confirmed regression in Jenkins 2.191 / Remoting 3.34 
 > https://issues.jenkins-ci.org/browse/JENKINS-59094 
 > 
 > I think it a serious obstacle for this version or for the tomorrow's 
 > security fix as a baseline. 
 > 
 > BR, Oleg 
 > 
 > On Monday, August 26, 2019 at 1:37:18 PM UTC+2, Mark Waite wrote: 
 > 
 > I've started testing 2.190 late Friday.  I did not find any 
 > immediate reasons to reject it as the LTS.  The security release 
 > scheduled for Wednesday seems to me like a good reason to prefer 
 > choosing 2.190 as a baseline, then update to the security release 
 as 
 > the baseline after it is delivered. 
 > 
 > I haven't investigated the startup failures reported in 
 > JENKINS-58912 and JENKINS-58938. 
 > 
 > I'm also concerned about JENKINS-58692 from the KDE project 
 > beginning in 2.186.  Jesse Glick investigated it and was unable 
 to 
 > duplicate it.  The KDE project found a workaround (install the 
 > symlinks plugin) and can't really explore other options because 
 it 
 > is their production system.  JENKINS-58692 will affect 2.186 and 
 > later, so it seems relevant to investigate further as a risk to 
 any 
 > LTS version we select. 
 > 
 > I prefer the upcoming security release as the baseline, but 
 > JENKINS-58912 and JENKINS-58938  need investigation before the 
 LTS 
 > is released. 
 > 
 > Mark Waite 
 > 
 > On Mon, Aug 26, 2019 at 6:28 AM Oleg Nenashev >>> > > wrote: 
 > 
 > I would vote for 2.187 as a baseline. FTR 
 > 
 https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE <
 https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE> for 
 > the mailing list selection process proposal. 
 > 
 > For the anticipated absence of a government meeting, we 
 will be 
 > selecting next LTS candidate here, on the mailing list. 
 The 
 > conclusion 
 > will be wrapped up no longer than Tuesday 27th COB UT 
 > 
 > 
 > We have a security release on Wednesday. Assuming it is 
 stable, 
 > we could use it as a baseline. 
 > 
 > If we discuss only released versions 
 > https://jenkins.io/changelog/#v2.189 
 >  has a pretty bad 
 > community rating. JENKINS-58912 
 >  / 

Re: Next LTS line selection open. Due 2019-08-27

[Oleg Nenashev]

Great to see the fix!  https://github.com/jenkinsci/jenkins/pull/4176 can
be trivially backported, so I think we can go ahead with 2.190 as a
baseline.

BR, Oleg


On Wed, Aug 28, 2019 at 12:54 PM Mark Waite 
wrote:

>
>
> On Tuesday, August 27, 2019 at 6:00:13 AM UTC-4, Oleg Nenashev wrote:
>>
>> For me 2.187 is a default pick. If somebody investigates  JENKINS-58912
>> 
>>  / JENKINS-58938  and
>> clarifies impact/possibility of a fix for .1, then I am fine with 190.
>> Cannot commit to investigate it unfortunately
>>
>> There are some reasons to want 2.190. Apart from emoji support for job
>> names (yey!) there are some more meaningful changes like plugin
>> installation parallelization for Setup Wizard (Jenkins Startup Experience),
>> security hardening, install-plugin fixes, and other changes which could
>> help LTS users.
>>
>>
> Gabriel Lavoie has submitted a pull request to fix those two issues.  The
> pull request is at https://github.com/jenkinsci/jenkins/pull/4176 and is
> related to the slow trigger monitor that was first released in 2.189.
>
> I haven't yet been able to interactively verify the problem myself, but am
> thrilled that Gabriel was able to do so and that a pull request has been
> submitted.
>
> That change leads me towards favoring 2.187, before that admin monitor was
> added.  I could be persuaded otherwise (especially considering the security
> fix that was announced for today), assuming we also have a fix for the
> remoting issue that was reported as
> https://issues.jenkins-ci.org/browse/JENKINS-59094
>
> Mark Waite
>
>
>> On Tuesday, August 27, 2019 at 11:50:34 AM UTC+2, ogondza wrote:
>>>
>>> So I guess that eliminates 2.191 as a choice for LTS. I do not feel that
>>> strong choosing between 2.190 and 2.187, and it appears Oleg and Mark
>>> leans that way.
>>>
>>> Any other inputs?
>>>
>>> On 27/08/2019 11.15, Oleg Nenashev wrote:
>>> > There is a confirmed regression in Jenkins 2.191 / Remoting 3.34
>>> > https://issues.jenkins-ci.org/browse/JENKINS-59094
>>> >
>>> > I think it a serious obstacle for this version or for the tomorrow's
>>> > security fix as a baseline.
>>> >
>>> > BR, Oleg
>>> >
>>> > On Monday, August 26, 2019 at 1:37:18 PM UTC+2, Mark Waite wrote:
>>> >
>>> > I've started testing 2.190 late Friday.  I did not find any
>>> > immediate reasons to reject it as the LTS.  The security release
>>> > scheduled for Wednesday seems to me like a good reason to prefer
>>> > choosing 2.190 as a baseline, then update to the security release
>>> as
>>> > the baseline after it is delivered.
>>> >
>>> > I haven't investigated the startup failures reported in
>>> > JENKINS-58912 and JENKINS-58938.
>>> >
>>> > I'm also concerned about JENKINS-58692 from the KDE project
>>> > beginning in 2.186.  Jesse Glick investigated it and was unable to
>>> > duplicate it.  The KDE project found a workaround (install the
>>> > symlinks plugin) and can't really explore other options because it
>>> > is their production system.  JENKINS-58692 will affect 2.186 and
>>> > later, so it seems relevant to investigate further as a risk to
>>> any
>>> > LTS version we select.
>>> >
>>> > I prefer the upcoming security release as the baseline, but
>>> > JENKINS-58912 and JENKINS-58938  need investigation before the LTS
>>> > is released.
>>> >
>>> > Mark Waite
>>> >
>>> > On Mon, Aug 26, 2019 at 6:28 AM Oleg Nenashev >> > > wrote:
>>> >
>>> > I would vote for 2.187 as a baseline. FTR
>>> >
>>> https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE <
>>> https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE> for
>>> > the mailing list selection process proposal.
>>> >
>>> > For the anticipated absence of a government meeting, we
>>> will be
>>> > selecting next LTS candidate here, on the mailing list.
>>> The
>>> > conclusion
>>> > will be wrapped up no longer than Tuesday 27th COB UT
>>> >
>>> >
>>> > We have a security release on Wednesday. Assuming it is
>>> stable,
>>> > we could use it as a baseline.
>>> >
>>> > If we discuss only released versions
>>> > https://jenkins.io/changelog/#v2.189
>>> >  has a pretty bad
>>> > community rating. JENKINS-58912
>>> >  /
>>> > JENKINS-58938
>>> >  looks to
>>> be
>>> > a pretty bad regression somewhere, but nobody has investigated
>>> > the issue so far. It is not clear when and why it happens. I
>>> am
>>> > not sure we are safe to go into LTS with it. So 2.187 is my
>>> >

Re: Next LTS line selection open. Due 2019-08-27

[Mark Waite]

On Tuesday, August 27, 2019 at 6:00:13 AM UTC-4, Oleg Nenashev wrote:
>
> For me 2.187 is a default pick. If somebody investigates  JENKINS-58912 
> 
>  / JENKINS-58938  and 
> clarifies impact/possibility of a fix for .1, then I am fine with 190. 
> Cannot commit to investigate it unfortunately
>
> There are some reasons to want 2.190. Apart from emoji support for job 
> names (yey!) there are some more meaningful changes like plugin 
> installation parallelization for Setup Wizard (Jenkins Startup Experience), 
> security hardening, install-plugin fixes, and other changes which could 
> help LTS users.
>
>
Gabriel Lavoie has submitted a pull request to fix those two issues.  The 
pull request is at https://github.com/jenkinsci/jenkins/pull/4176 and is 
related to the slow trigger monitor that was first released in 2.189.

I haven't yet been able to interactively verify the problem myself, but am 
thrilled that Gabriel was able to do so and that a pull request has been 
submitted.

That change leads me towards favoring 2.187, before that admin monitor was 
added.  I could be persuaded otherwise (especially considering the security 
fix that was announced for today), assuming we also have a fix for the 
remoting issue that was reported as 
https://issues.jenkins-ci.org/browse/JENKINS-59094

Mark Waite
 

> On Tuesday, August 27, 2019 at 11:50:34 AM UTC+2, ogondza wrote:
>>
>> So I guess that eliminates 2.191 as a choice for LTS. I do not feel that 
>> strong choosing between 2.190 and 2.187, and it appears Oleg and Mark 
>> leans that way. 
>>
>> Any other inputs? 
>>
>> On 27/08/2019 11.15, Oleg Nenashev wrote: 
>> > There is a confirmed regression in Jenkins 2.191 / Remoting 3.34 
>> > https://issues.jenkins-ci.org/browse/JENKINS-59094 
>> > 
>> > I think it a serious obstacle for this version or for the tomorrow's 
>> > security fix as a baseline. 
>> > 
>> > BR, Oleg 
>> > 
>> > On Monday, August 26, 2019 at 1:37:18 PM UTC+2, Mark Waite wrote: 
>> > 
>> > I've started testing 2.190 late Friday.  I did not find any 
>> > immediate reasons to reject it as the LTS.  The security release 
>> > scheduled for Wednesday seems to me like a good reason to prefer 
>> > choosing 2.190 as a baseline, then update to the security release 
>> as 
>> > the baseline after it is delivered. 
>> > 
>> > I haven't investigated the startup failures reported in 
>> > JENKINS-58912 and JENKINS-58938. 
>> > 
>> > I'm also concerned about JENKINS-58692 from the KDE project 
>> > beginning in 2.186.  Jesse Glick investigated it and was unable to 
>> > duplicate it.  The KDE project found a workaround (install the 
>> > symlinks plugin) and can't really explore other options because it 
>> > is their production system.  JENKINS-58692 will affect 2.186 and 
>> > later, so it seems relevant to investigate further as a risk to any 
>> > LTS version we select. 
>> > 
>> > I prefer the upcoming security release as the baseline, but 
>> > JENKINS-58912 and JENKINS-58938  need investigation before the LTS 
>> > is released. 
>> > 
>> > Mark Waite 
>> > 
>> > On Mon, Aug 26, 2019 at 6:28 AM Oleg Nenashev > > > wrote: 
>> > 
>> > I would vote for 2.187 as a baseline. FTR 
>> > 
>> https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE <
>> https://groups.google.com/forum/#!topic/jenkinsci-dev/oQ8PD1hgYBE> for 
>> > the mailing list selection process proposal. 
>> > 
>> > For the anticipated absence of a government meeting, we 
>> will be 
>> > selecting next LTS candidate here, on the mailing list. The 
>> > conclusion 
>> > will be wrapped up no longer than Tuesday 27th COB UT 
>> > 
>> > 
>> > We have a security release on Wednesday. Assuming it is stable, 
>> > we could use it as a baseline. 
>> > 
>> > If we discuss only released versions 
>> > https://jenkins.io/changelog/#v2.189 
>> >  has a pretty bad 
>> > community rating. JENKINS-58912 
>> >  / 
>> > JENKINS-58938 
>> >  looks to 
>> be 
>> > a pretty bad regression somewhere, but nobody has investigated 
>> > the issue so far. It is not clear when and why it happens. I am 
>> > not sure we are safe to go into LTS with it. So 2.187 is my 
>> > preference (2.188 was burned) 
>> > 
>> > BR, Oleg 
>> > 
>> > 
>> > On Monday, August 26, 2019 at 11:00:47 AM UTC+2, ogondza wrote: 
>> > 
>> > For the anticipated absence of a government meeting, we 
>> will be 
>> >