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

[Jesse Glick]

On Tue, Aug 27, 2019 at 12:50 PM 'Gavin Mogan' via Jenkins Developers
 wrote:
> I strongly recommend at least setting up project > scm > url

For example, when using an archetype (recommended):

https://github.com/jenkinsci/archetypes/blob/e546bcbb236539de7c2a958ccddfac190f44efb9/empty-plugin/src/main/resources/archetype-resources/pom.xml#L30

-- 
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/CANfRfr2pbWZKk%3DZAGxfhWo9RAczR5XxKBnaszx%2BLgs1OOtA8mw%40mail.gmail.com.

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

[Marky Jackson]

+1

> On Aug 27, 2019, at 9:50 AM, 'Gavin Mogan' via Jenkins Developers 
>  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/CAG%3D_DutPg%3DDD8ZseEW1i6VZJ-QMjK0aGs%2BaC34jeDR9u-OOj7w%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/3525D81F-BBC2-4CAF-9A47-ACE4F2C4FE64%40gmail.com.

Re: Hosting process

['Gavin Mogan' via Jenkins Developers]

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

Hosting process

[Slide]

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.

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

['Gavin Mogan' via Jenkins Developers]

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/CAG%3D_DutPg%3DDD8ZseEW1i6VZJ-QMjK0aGs%2BaC34jeDR9u-OOj7w%40mail.gmail.com.

Re: Impact of BOM on plugin versions

[Jesse Glick]

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.

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

[Matt Sicker]

That's in 2.189 from https://github.com/jenkinsci/jenkins/pull/4124

On Tue, Aug 27, 2019 at 10:17 AM Mark Waite  wrote:
>
> Matt,
>
> Which Jenkins weekly is the first version that includes plugin install 
> batching?
>
> On Tue, Aug 27, 2019 at 11:11 AM Matt Sicker  wrote:
>>
>> I'd really love to see the plugin install batching feature integrated
>> into LTS as that comes up a _lot_ during local testing, especially
>> whenever I work on security fixes for Jenkins as we use LTS branches
>> for development there.
>>
>> On Tue, Aug 27, 2019 at 6:09 AM Mark Waite  wrote:
>> >
>> > I hope to spend some hours investigating those two after work today 
>> > (JENKINS-58938 and JENKINS-58912).  I'm traveling so have less access to 
>> > my environment, but will spend some time trying to duplicate the issue and 
>> > identify the change which caused it.
>> >
>> > 2.187 seems reasonable, assuming the security fix is backported.  Would 
>> > the fix to those two issues be a critical factor in choosing 2.190 
>> > instead?  2.190 does not have remoting 3.34, so it avoids that regression.
>> >
>> > On Tue, Aug 27, 2019 at 6:00 AM 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.
>> >>
>> >> 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 
>> >>> >  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 

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

[Mark Waite]

Matt,

Which Jenkins weekly is the first version that includes plugin install
batching?

On Tue, Aug 27, 2019 at 11:11 AM Matt Sicker  wrote:

> I'd really love to see the plugin install batching feature integrated
> into LTS as that comes up a _lot_ during local testing, especially
> whenever I work on security fixes for Jenkins as we use LTS branches
> for development there.
>
> On Tue, Aug 27, 2019 at 6:09 AM Mark Waite 
> wrote:
> >
> > I hope to spend some hours investigating those two after work today
> (JENKINS-58938 and JENKINS-58912).  I'm traveling so have less access to my
> environment, but will spend some time trying to duplicate the issue and
> identify the change which caused it.
> >
> > 2.187 seems reasonable, assuming the security fix is backported.  Would
> the fix to those two issues be a critical factor in choosing 2.190
> instead?  2.190 does not have remoting 3.34, so it avoids that regression.
> >
> > On Tue, Aug 27, 2019 at 6:00 AM 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.
> >>
> >> 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 <
> o.v.n...@gmail.com
> >>> > > 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, 

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

[Matt Sicker]

I'd really love to see the plugin install batching feature integrated
into LTS as that comes up a _lot_ during local testing, especially
whenever I work on security fixes for Jenkins as we use LTS branches
for development there.

On Tue, Aug 27, 2019 at 6:09 AM Mark Waite  wrote:
>
> I hope to spend some hours investigating those two after work today 
> (JENKINS-58938 and JENKINS-58912).  I'm traveling so have less access to my 
> environment, but will spend some time trying to duplicate the issue and 
> identify the change which caused it.
>
> 2.187 seems reasonable, assuming the security fix is backported.  Would the 
> fix to those two issues be a critical factor in choosing 2.190 instead?  
> 2.190 does not have remoting 3.34, so it avoids that regression.
>
> On Tue, Aug 27, 2019 at 6:00 AM 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.
>>
>> 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 
>>> >  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
>>> > selecting next LTS candidate here, on the mailing list. The
>>> > conclusion
>>> > will be wrapped up no 

Re: Impact of BOM on plugin versions

[Matt Sicker]

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). Also, I
started using that bom in credentials-plugin, so it's somewhat amusing
that it imports a dependencyManagement for itself, though it doesn't
appear to adversely affect the build at all.

On Mon, Aug 26, 2019 at 4:11 PM Jesse Glick  wrote:
>
> On Mon, Aug 26, 2019 at 4:46 PM Mark Waite  wrote:
> > I've generally preferred to keep the dependency at oldest version I can 
> > reasonably trust.
>
> Well, the BOM is designed to give you the newest version compatible
> with your LTS line.
>
> > I believe in this case that the credentials plugin 2.2.0 is the required 
> > dependency from the BOM because it is the version which includes the most 
> > recent security fix for the credentials plugin.
>
> No, it is just the latest available version according to Dependabot.
>
> > Am I correct [that using the BOM] means [users] will generally have newer 
> > dependencies than they did in the past?
>
> Yes.
>
> Now as to whether you _want_ to publish new releases of one plugin
> that depend only on old releases of another plugin, this is certainly
> a matter of judgment. You would be offering a special benefit to the
> user that spends an hour looking over the *Updates* tab, poring
> through release notes, and hand-picking certain updates according to
> features or fixes they think they want. But your plugin’s tests will
> only be verifying compatibility with a rather old snapshot of the
> Jenkins ecosystem, and you will likely even be writing new code which
> calls APIs that were deprecated years ago.
>
> The assumption behind the BOM is that most people just accept all
> updates most of the time, and if something breaks they will just roll
> everything back, or tolerate it until a fix is released; plugin
> maintainers should “fixing forward”. (Jenkins core is somewhat
> artificially given a special position in this view, as something that
> is cumbersome and particularly risky to update.)
>
> --
> 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/CANfRfr2FysL-2e6PPtkdHHYXFEJkFhhcstK1BV3eu-WWLT%3Dopw%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/CAEot4oxccC6CrehBM%2BFjgXyXTUM2x%2BNgV9pUzr284RBzMdPcHw%40mail.gmail.com.

Re: Replace authorize-project-plugin

[Stephen Connolly]

On Tuesday, 27 August 2019 09:16:40 UTC+1, ikedam wrote:
>
> Hi, 
>
> I’m Ikedam,  a maintainer of authorize-project-plugin. 
> https://plugins.jenkins.io/authorize-project 
>
> Authorize-project-plugin doesn’t support features of modern Jenkins, such 
> as pipelines, multibranch and JCaC. 
> Making things worse, authorize-project-plugin is the only implementation 
> for QueueItemAuthenticator as far as I know. 
>
> Authorize-project-plugin is originally designed for legacy Jenkins, that 
> is, expected to use with freestyle projects and matrix projects, and 
> expected to configured with web browsers. And I believe it’s fundamentally 
> incompatible with modern Jenkins. 
>
> It might be possible to extend or redesign this plugin and to have it 
> applicable to modern Jenkins, but I’m afraid that it’s not reasonable as it 
> mainly costs not for new features, but rather for preserving backward 
> compatibilities. 
>
> What I want to do here are: 
>
> * Request a new plugin implementing QueueItemAuthenticator, supporting 
> modern Jenkins and which will replace and deprecate 
>  authorize-project-plugin. 
> * Unfortunately I won’t join that development. Sorry. 
>
> * Ask depelopers whether QueueItemAuthenticator is what we actually want, 
> or there can be alternate ways to control permissions of builds: 
> * I originally developed authorize-project-plugin for 
> copyartifact-plugin to control the permission to copy artifacts from other 
> builds. But I believe it’s easier to control that permission with 
> CopyArtifactPermissionProperty, which defines jobs allowed to access to 
> artifacts. 
> * I believe users want to define permissions not bound to actual 
> specific users such as those in LDAP, or Active Directory. But Jenkins 
> doesn’t provide mechanisms for authentications not bound to specific users, 
> like sevice accounts in Google Cloud Platform. 
>

So if you use the https://github.com/jenkinsci/impersonation-plugin that I 
wrote *but never actually got around to releasing* that will let a user 
impersonate any LDAP group they are a member of... then you can configure 
credentials and builds to run as that group... that way other users in the 
same group can configure etc.

It's not service accounts, but it is very close... otoh it requires a 
security realm with groups (e.g. LDAP or ActiveDirectory)
 

> * I expect QueueItemAuthenticator can be replaced with other 
> permission mechanisms not bound to specific users, like permissions between 
> jobs (generalizing CopyArtifactPermissionProperty) or permissions for 
> credentials from jobs (folder-scoped credentials might meet that). 
> * I don’t know actual usecases of QueueItemAuthenticatorcan and there 
> might be usecases that cannot be replaced with other mechanisms. 
>
> Regards, 
> Ikedam 
>

-- 
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/6476f25d-197e-46e8-a2a4-02c087170497%40googlegroups.com.

Re: Replace authorize-project-plugin

[Jesse Glick]

First of all, thank you for thinking about what the project needs,
rather than focusing narrowly on fixing problems with an existing
design.

On Tue, Aug 27, 2019 at 4:16 AM ikedam  wrote:
> I believe users want to define permissions not bound to actual specific users 
> such as those in LDAP, or Active Directory. But Jenkins doesn’t provide 
> mechanisms for authentications not bound to specific users, like sevice 
> accounts in Google Cloud Platform.

Right, this is a very longstanding need. It is usually tracked
alongside security realm multiplexing as JENKINS-15063, though the
service account concept is a more limited feature that might be better
implemented directly.

> I expect QueueItemAuthenticator can be replaced with other permission 
> mechanisms not bound to specific users, like permissions between jobs

I might not phrase it as “permissions” because that might be taken to
mean that such a system must be based on Jenkins’ `ACL` + `Permission`
+ `Authentication`. You _could_ pick a design based on service
accounts configured in the `AuthorizationStrategy`, but there are
alternative choices. For reference, CloudBees Core includes a
different design to solve a subset of this problem (what
`QueueItemAuthenticator` would let you control in the case of
`Job.BUILD` permission):

https://go.cloudbees.com/docs/cloudbees-core/cloud-admin-guide/trigger-restrictions/

-- 
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/CANfRfr0yNdcsCa_1nxqOw-CHoSOZaUK2BA-%3DhKDV-kuMQHUobg%40mail.gmail.com.

Re: Request to be made maintainer of ant-plugin

[Jesse Glick]

On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  wrote:
> a default assignee for the component

As always, I prefer there to be no default assignee for a JIRA
component. It is not a helpful concept IMO. If and when I decide to
tackle an issue, I will assign it to myself.

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

Re: Request to be made maintainer of ant-plugin

[Oleg Nenashev]

Permissions have been transferred.
Jesse and Francisco, could you please agree about a default assignee for 
the component?

On Friday, August 23, 2019 at 7:21:22 PM UTC+2, Jesse Glick wrote:
>
> On Fri, Aug 23, 2019 at 5:25 AM Francisco Javier Fernandez 
> > wrote: 
> > I would be interested in becoming co-maintainer if possible 
>
> +1 as far as I am concerned. 
>

-- 
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/342757d2-a431-4edb-937b-817d7615f5e0%40googlegroups.com.

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

[Mark Waite]

I hope to spend some hours investigating those two after work today (
JENKINS-58938  and
JENKINS-58912 ).  I'm
traveling so have less access to my environment, but will spend some time
trying to duplicate the issue and identify the change which caused it.

2.187 seems reasonable, assuming the security fix is backported.  Would the
fix to those two issues be a critical factor in choosing 2.190 instead?
2.190 does not have remoting 3.34, so it avoids that regression.

On Tue, Aug 27, 2019 at 6:00 AM 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.
>
> 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
>> > selecting next LTS candidate here, on the mailing list. The
>> > conclusion
>> > will be wrapped up no longer than Tuesday 27th COB UTC
>> time.
>> > Feel free
>> > to share your thoughts here.
>> >
>> > ---
>> >
>> > I believe we affectively only have 

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

[Oleg Nenashev]

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.

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 
> > selecting next LTS candidate here, on the mailing list. The 
> > conclusion 
> > will be wrapped up no longer than Tuesday 27th COB UTC time. 
> > Feel free 
> > to share your thoughts here. 
> > 
> > --- 
> > 
> > I believe we affectively only have 2 candidates[1], 2.189 
> > and 2.190. 
> > Since 2.190 has relatively few changes in it, all minor, got 
> > 2 weeks of 
> > soaking with nothing but positive community feedback, I vote 
> > to choose 
> > that despite being the latest weekly published. 
> > 
> > [1] https://jenkins.io/changelog/ 
> > 
> > -- 
> > oliver 
> > 
> > -- 
> > You received this message because you are subscribed to the 
> > Google Groups "Jenkins Developers" group. 
> > To unsubscribe from this group and stop receiving 

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

[Oliver Gondža]

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 
 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
selecting next LTS candidate here, on the mailing list. The
conclusion
will be wrapped up no longer than Tuesday 27th COB UTC time.
Feel free
to share your thoughts here.

---

I believe we affectively only have 2 candidates[1], 2.189
and 2.190.
Since 2.190 has relatively few changes in it, all minor, got
2 weeks of
soaking with nothing but positive community feedback, I vote
to choose
that despite being the latest weekly published.

[1] https://jenkins.io/changelog/

-- 
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 jenkin...@googlegroups.com .
To view this discussion on the web visit

https://groups.google.com/d/msgid/jenkinsci-dev/2577f42d-5a15-4995-b5f8-a97de6a60fe7%40googlegroups.com

.



-- 
Thanks!

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/8346a1c4-ca52-4f6f-b89a-f00bb0eb48e2%40googlegroups.com 
.



--
oliver

--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop 

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

[Oleg Nenashev]

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 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 
>>> selecting next LTS candidate here, on the mailing list. The conclusion 
>>> will be wrapped up no longer than Tuesday 27th COB UTC time. Feel free 
>>> to share your thoughts here. 
>>>
>>> --- 
>>>
>>> I believe we affectively only have 2 candidates[1], 2.189 and 2.190. 
>>> Since 2.190 has relatively few changes in it, all minor, got 2 weeks of 
>>> soaking with nothing but positive community feedback, I vote to choose 
>>> that despite being the latest weekly published. 
>>>
>>> [1] https://jenkins.io/changelog/ 
>>>
>>> -- 
>>> 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 jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2577f42d-5a15-4995-b5f8-a97de6a60fe7%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Thanks!
> 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/8346a1c4-ca52-4f6f-b89a-f00bb0eb48e2%40googlegroups.com.

Replace authorize-project-plugin

[ikedam]

Hi,

I’m Ikedam,  a maintainer of authorize-project-plugin.
https://plugins.jenkins.io/authorize-project

Authorize-project-plugin doesn’t support features of modern Jenkins, such as 
pipelines, multibranch and JCaC.
Making things worse, authorize-project-plugin is the only implementation for 
QueueItemAuthenticator as far as I know.

Authorize-project-plugin is originally designed for legacy Jenkins, that is, 
expected to use with freestyle projects and matrix projects, and expected to 
configured with web browsers. And I believe it’s fundamentally incompatible 
with modern Jenkins.

It might be possible to extend or redesign this plugin and to have it 
applicable to modern Jenkins, but I’m afraid that it’s not reasonable as it 
mainly costs not for new features, but rather for preserving backward 
compatibilities.

What I want to do here are:

* Request a new plugin implementing QueueItemAuthenticator, supporting modern 
Jenkins and which will replace and deprecate  authorize-project-plugin.
* Unfortunately I won’t join that development. Sorry.

* Ask depelopers whether QueueItemAuthenticator is what we actually want, or 
there can be alternate ways to control permissions of builds:
* I originally developed authorize-project-plugin for copyartifact-plugin 
to control the permission to copy artifacts from other builds. But I believe 
it’s easier to control that permission with CopyArtifactPermissionProperty, 
which defines jobs allowed to access to artifacts.
* I believe users want to define permissions not bound to actual specific 
users such as those in LDAP, or Active Directory. But Jenkins doesn’t provide 
mechanisms for authentications not bound to specific users, like sevice 
accounts in Google Cloud Platform.
* I expect QueueItemAuthenticator can be replaced with other permission 
mechanisms not bound to specific users, like permissions between jobs 
(generalizing CopyArtifactPermissionProperty) or permissions for credentials 
from jobs (folder-scoped credentials might meet that).
* I don’t know actual usecases of QueueItemAuthenticatorcan and there might 
be usecases that cannot be replaced with other mechanisms.

Regards,
Ikedam

-- 
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/d0bed924-83ec-4c5e-9ce4-04a03363fd27%40googlegroups.com.