Re: Error: Could not find or load main class com.mathworks.polyspace.jenkins.PolyspaceHelpers

[Baptiste Mathus]

o/

Usually the best way to implement something is to look at how other plugins
are doing it. The easiest way to find these existing implems is using
https://www.jenkins.io/doc/developer/extensions/jenkins-core/#toolinstallation

Then, beware to read a few examples of ideally well-known plugins (theory
being that there's greater chance to see idiomatic Jenkins code in a plugin
installed 100k times, than one installed 10 :)).

Cheers

Le dim. 3 mars 2024 à 08:46, Stéphane BOBIN  a
écrit :

> Hi Daniel!
>
> I like the idea. Do you have some more guidance, please? I found this:
> https://javadoc.jenkins.io/hudson/tools/ToolInstallation.html. But it
> does not explain a lot. Can you point me to the doc for the various items
> you suggest? A big thanks for your help!
>
> -- Stéphane BOBIN
>
> Le sam. 2 mars 2024 à 00:40, 'Daniel Beck' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> a écrit :
>
>>
>>
>> On Fri, Mar 1, 2024 at 11:43 PM Stéphane BOBIN <
>> stephane.bobin...@gmail.com> wrote:
>>
>>> - What is the recommended and secure way to have scripts on agents to
>>> call utilities from the plugin?
>>>
>>
>> It's not a common enough use case to have a general recommendation.
>>
>> Some ideas: publish the utilities separately rather than as part of the
>> plugin, integrate them as tools into Jenkins (ToolInstallation /
>> ToolInstaller), implement their functionality as build step(s), provide a
>> build step to copy them to the workspace, or make them available for
>> download from Jenkins like the agent.jar (with some care to not allow
>> downloading anything else).
>>
>> --
>> 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/CAMo7PtJ%2BvW36L2Qhf4gqc2ebO09UQV7WweWByduxgpsXwhT9Pg%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/CAMQQ2smfvD2JnTjCFrFWP4sSXgZgf9cOsQ_WPPTQ5S_m-tS3Jw%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/CANWgJS6f%2Bye6cet4G2PG%3DH0cyaykJiAcmQzOn-Bi_fD9SzSwMg%40mail.gmail.com.

[JENKINS-71661] extended-choice-parameter plugin: merge or adopt? :)

[Baptiste Mathus]

Hey all,

FYI, we've recently uncovered an issue in the extended-choice-parameter
plugin.
In short, it is unconditionally setting up a polyfill for CustomEvents
.
This is breaking one of our plugins that is sending Custom Events.

We have filed a fix at
https://github.com/jenkinsci/extended-choice-parameter-plugin/pull/98.

I have CCed the last known maintainer (hello Chas!): I'm moving a bit fast,
granted, but given 1) the last commit was in April, and 2) this is totally
breaking our plugin, I thought I'd send at least a heads-up here so it
starts moving :-).

@Chas if you're not actively maintaining this plugin anymore, just let us
know and I'm happy to take care of it by adopting the plugin. If you still
are, I'd appreciate a review and hopefully a merge of
https://github.com/jenkinsci/extended-choice-parameter-plugin/pull/98 :-).

Thanks!

-- Baptiste
PS: I checked the jenkinsci org, and AFAICT the other plugins that play
with CustomEvent
 do
use an if(window.customEvent !== something) construct to install it only
when missing. (which is how a polyfill/shim should be set up)

-- 
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/CANWgJS7CbbeKaBrCpO55gK2EN8g0yENYmXnVR1Cgx%3DwvLpJYsw%40mail.gmail.com.

Re: Requesting admin access to the jenkinsci GitHub organization

[Baptiste Mathus]

+1.

Le lun. 5 juin 2023 à 19:33, Srikanth Jana  a
écrit :

> +1 from me
>
> On Mon, Jun 5, 2023 at 11:01 PM Alexander Brandes 
> wrote:
>
>> +1 for Basil
>>
>> On Mon 5. Jun 2023 at 19:30, Mark Waite 
>> wrote:
>>
>>>
>>>
>>> On Monday, June 5, 2023 at 11:29:18 AM UTC-6 m Basil Crow wrote:
>>>
>>> I would like to become an organization administrator of the jenkinsci
>>> GitHub organization. This would facilitate various efforts I am
>>> involved with, such as repository transfers.
>>>
>>>
>>> +1 from me.
>>>
>>> --
>>> 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/78809aba-d9ca-4d43-98bf-858811577121n%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/CAP9joaGh28MKR0jSRptwGGhnAKNn_7C8W2aTQVgzpqmsyjtgeQ%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/CAJxAiNDnHRF5BRtESwKfdsmH9pi698V24TjXTMPXCTfOEUmK4Q%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/CANWgJS7QcnLsR4ZRR5tU9y6fWsQ2dKP2xdGCpx84V44ga3xhAg%40mail.gmail.com.

2.387.2 RC?

[Baptiste Mathus]

Hi all,

@Tim in the calendar, the 2.387.2 RC is supposed to go out this Wednesday
the 22nd .
Is the calendar outdated, or are we going to start the backporting process
soon?

Thanks!

-- Baptiste

-- 
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/CANWgJS6F0jn4OiLXHNNt4Dg07xpdZGo%2B5RMuKkz9WbwrOt21%3DQ%40mail.gmail.com.

Re: Press Contacts

[Baptiste Mathus]

+1 to remove/rework this and just point to the board's email.

1) I did receive many such sollications in the past, many legitimate. But
in 99% of the cases, I have mostly just forwarded requests to the board
when being contacted through this.
2)  I do not think I have received anything in the last 1+ year at least
anyway

Cheers


Le ven. 10 févr. 2023 à 13:10, Alexander Brandes  a
écrit :

> +1 from me, a rework is overdue.
>
> On Friday, 10 February 2023 at 12:55:11 UTC+1 Oleg Nenashev wrote:
>
>> +1 too. We can just drop everything and offer a Jenkins Board and
>> Security team contacts instead
>>
>>
>> On Friday, February 10, 2023 at 1:09:32 AM UTC+1 Alyssa wrote:
>>
>>> +1 for dropping the contacts. IIRC as long as i've been with the project
>>> there hasn't really been press request(s) either.
>>> Alternatively there's CDF, perhaps they can be that fitler (contact) for
>>> Jenkins.  Just a thought.
>>>
>>> alyssa
>>>
>>> On Thu, Feb 9, 2023 at 12:30 PM 'Gavin Mogan' via Jenkins Developers <
>>> jenkin...@googlegroups.com> wrote:
>>>
 Re

 https://github.com/jenkins-infra/jenkins.io/blob/master/content/press.adoc#press-contacts

 I'm planning on a putting in a PR to remove myself from the contacts.
 In the almost two years of me being on the list, i've never had a
 legitimate email, its all spam about having sponsored posts.

 I also think most (maybe 50%) of the people listed are no longer
 actively engaged with the project, so probably not the best to a filter for
 press.

 My vote is to just drop the contacts section and use the forum or
 something. Private communication isn't really great for the projectanyways.

 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-de...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuuKa%2Boqh-O-xinqv1K2T%2BietBgtoNe%2B75Au2_mmvgZSkQ%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/f5f38ef9-5d19-4dcf-b81f-bc6233c8a639n%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/CANWgJS5WMfyStjeidNstq0rudf-ddJRSbfR1a914BhB_9-T1nQ%40mail.gmail.com.

Re: Proposal to ensure new plugin hosting requests use Maven instead of Gradle

[Baptiste Mathus]

+1.

At least such a move will make it very explicit for any new plugin that
only Maven really has /production/ support for Jenkins plugin dev.

I think that we should still "allow" new plugins to use Gradle if they wish
so. But then they'll be very well aware that they got to be ready for a lot
of pain and much meta-work around the tooling itself for developing their
plugins.
Which right now might be overlooked by new developers joining the community
and thinking that choosing one or another is simply a matter of taste and
habits.

Le mer. 7 déc. 2022 à 15:19, Basil Crow  a écrit :

> +1
>
> On Wed, Dec 7, 2022 at 2:20 AM Alexander Brandes 
> wrote:
> >
> > Hey everyone,
> >
> > the Gradle JPI plugin lacks fundamental support of the jenkins.io
> infrastructure.
> > There's no support for automated releases (CD, JEP-229), missing
> metadata for the plugin page and a few other limitations, which don't make
> it a great experience using it.
> >
> > Additionally, worth to note, the components mentioned above aren't new.
> People are proactively switching away from Gradle to Maven for better
> support and acceptance of our tooling, see ivy-plugin/49 for example.
> >
> > For the reasons stated, I would like to propose, that new plugin hosting
> requests use Maven, to have better toolchain support.
> > I would be ready to lift this restriction again if the JPI plugin
> developers provide the same scope of tools like we have for Maven.
> >
> > Best,
> > Alexander Brandes, for the hosting team
> >
> > --
> > 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/bb8f56d3-727b-481a-9132-17bf5eddbbcdn%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/CAFwNDjq9xnyvJFoB33n07jORm7Hw6fSBf8FY5ho5FdGMDAiKug%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/CANWgJS7Ngft3CgytKLxq5NJ8qWFeNGGq_XXFWmp1dhS-hRgZFw%40mail.gmail.com.

Re: Building an hpi file?

[Baptiste Mathus]

analysis-model is a jar, not a plugin. So it will create a jar as expected.
It is used by other plugins I think (cannot check just now).

What are you trying to achieve?

Le mer. 25 mai 2022 à 21:18, Simon Matthews  a
écrit :

> I am attempting to build a modified version of the analysis-model plugin.I
> think that I need to create an hpi file which I can then install in my
> jenkins installation, but if this is not correct, please tell me.
>
> It's not clear to me how to do this from the command line: I think it has
> changed over time, so there are plenty of old pages that are now incorrect.
>
> I think that I need to use maven to build the "hpi:hpi" target, but this
> may be wrong. In any case, attempts to do this result in an error: I have
> tried other targets, such as "package" and "install". They appear to
> complete the build successfully, but don't create an hpi file.
>
> Running:
> ~/bin/apache-maven-3.8.5/bin/mvn hpi:hpi
> results in:
> [ERROR] Failed to execute goal
> org.jenkins-ci.tools:maven-hpi-plugin:3.29-rc1263.227a_29289ce3:hpi
> (default-cli) on project analysis-model: Failed to determine Jenkins
> version this plugin depends on. -> [Help 1]
> I have tried adding the following to my pom.xml file:
> 2.332.3
> but it doesn't help.
>
> What am I doing wrong?
>
> Simon
>
> --
> 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/549954d3-3d28-46dd-a3b8-2d450474c87an%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/CANWgJS5E-XJLxeTps6OgLZhpjh2cL0j1ZZtLTBZX%3DydYzAJMAg%40mail.gmail.com.

Re: winp maintainer

[Baptiste Mathus]

Is winp used outside of Jenkins?

Afaik we did move already a few components core to Jenkins to the Jenkinsci
GitHub org. Would it make sense to consider moving this one too? Then I
assume we'd give permissions to the core team to it?

-- Baptiste

Le ven. 11 févr. 2022 à 22:41, 'James Nord' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

> Hi all,
>
> Jenkins has a dependency on https://github.com/kohsuke/winp but it now
> seems like there is no one active in the project that can release it.  (
> https://github.com/kohsuke/winp/pull/69#pullrequestreview-867992611).
>
> Has anyone got the inclination and time and environment to want to step up
> as a maintainer for it?
>
> Additionally I looked at the new Java9 process API and it allows cross
> platform process enumeration but not retrieving environment variables, and
> changing to jna appears non trivial as there is no single windows API call.
>
> /James
>
>
> --
> Sent from my phone, please excuse the brevity, typos and auto-correct
> issues.
>
> --
> 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/CAPcEHyeDNWeo0dK%2BwYmo%3Diih1EcRUVfs8-PaydspXxGRcP8izg%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/CANWgJS4HtS-Z8ABWuQfi5zq4q7_GjdM5cB2Lbrk%3DPchpA0Uz2g%40mail.gmail.com.

Adopt MSTestRunner plugin

[Baptiste Mathus]

Hi all,

I would like to adopt this plugin. I'm CCing the two existing declared
releasers/maintainers on the permission file.

I've filed
https://github.com/jenkins-infra/repository-permissions-updater/pull/2349

Thanks.

-- Baptiste

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

Re: Plugin testers / early adopters

[Baptiste Mathus]

I think you just want to use the users mailing list to try and find
interested users.

And for lessening the impact, you may want to use an experimental release
so they're only visible to users who opt-in:
https://www.jenkins.io/doc/developer/publishing/releasing-experimental-updates/

Cheers

Le mar. 25 janv. 2022 à 12:31, Tony Noble  a écrit :

> Apologies if I'm way off track or asking something there's a well known
> answer to, but:
>
> Is there a mailing list or group for end users who are willing to test
> incremental builds of plugins and report back?
>
> In this instance, I'm at the point where I'm ready to release the
> XTrigger-lib-related plugins (urltrigger, fstrigger, ivytrigger etc) which
> have been updated to use the newly-released XTrigger-API plugin, which in
> turn has been updated to use the EnvInject-API plugin instead of EnvInject
> lib.  In theory, this is a non-breaking change, as no functionality of
> configuration should be changing, but obviously under the hood, it's pretty
> significant.
>
> I'm updating the versions of the plugins from 0.xx to 1.xx to signify a
> major update, but is there anything else I can do to lessen any potential
> shock to end-users?  If an 'early adopter' group exists, that would be
> ideal, but any other suggestions would be welcome.
>
> Tony
>
> --
> 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/CAEWqh9GNsDVkaBu4s0SJsZ1hFLD0HL%3DrVGhw4Jvuw4cf4fGZpQ%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/CANWgJS51bNxMMWbO3pcAmjT2Df6hWVVSSw6-sV%2BR7R8AUAxG0A%40mail.gmail.com.

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

[Baptiste Mathus]

I like the planning idea, I think updating the minimum in Feb 2021 for
weeklies and hence June for LTS is a bit too aggressive.

I think we should *at least* target the LTS _after_ June.

And in the meantime keep communicating on this timeline like we had done
for Java 8.
Blogs. Tweet encouraging to update to Java 11, etc. Messages on the users
ML...

Le mar. 21 déc. 2021 à 21:01, Tim Jacomb  a écrit :

> Back to Java 11 :)
>
> (I suggest another thread for Java 17 Basil has been doing some great work
> there)
>
> There's been an 'admin monitor' around for quite a while now encouraging
> users to upgrade to Java 11 if they are on 8.
>
> The JavaVersionRecommendationAdminMonitor
> 
>  was
> introduced in (approx):
>
>- 2.296 - 1st June 2021
>- 2.303.1 - 25th August 2021
>
> Since that went in Java 11 usage skyrocketed according to
> https://stats.jenkins.io/plugin-installation-trend/jvms.json
>
> Basil has created a PR 
> for updating the monitor with a specific date (to be filled in) for
> deprecation.
>
> I think we should target the LTS after next for dropping Java 8 support.
>
> That would be:
>
>- Weekly - 2nd February (week after baseline selection for next LTS)
>- LTS - approx 7th June (roughly when ths LTS after next will be
>released)
>
> Next LTS would also be possible, we could do:
>
>- Weekly - January 19th
>- LTS - March 9th
>
> Thoughts?
>
> Thanks
> Tim
>
> On Mon, 20 Dec 2021 at 22:19, Basil Crow  wrote:
>
>> On Mon, Dec 20, 2021 at 1:53 PM 'Jesse Glick' via Jenkins Developers
>>  wrote:
>> >
>> > Is this mostly about Servlet API types, or other EE packages?
>>
>> Servlet types and JavaMail were the most common cases I saw in the
>> prototype, along with a new package namespace for FileUpload to go
>> along with the new servlet types. Seems more straightforward to do one
>> large Jakarta migration rather than several smaller ones. This is
>> going to be a major disruption anyway, so might as well just get it
>> over with. The only migration I didn't tackle in the prototype was the
>> Jakarta Dependency Injection API, because Guice doesn't support the
>> new types yet (google/guice#1383). I imagine Guice will support them
>> at some point in the future; Spring Security and Commons FileUpload
>> only support the new types in snapshot releases at present. My gut
>> feeling is that this migration will probably kick into full gear
>> around late 2022 or early 2023.
>>
>> --
>> 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/CAFwNDjpqkX2mBsBoh7LrwCBJtU%2B3ZGdvR-T9c3A3ij2mew-3ww%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie-uApHh6mDCSWOMzR%2BWBNC5ZZmjdVDXGd2cS8iaDtc3Q%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/CANWgJS6KhURORvDwO7CMfw%3DuLe7QTg2poAojwu6WuX50_sbyLQ%40mail.gmail.com.

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

[Baptiste Mathus]

Would be interesting to look at the numbers on the JVM version for only
recent Jenkins versions, say for the past 18 to 24+ months.
I had done so for
https://www.jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/ but
I'm not sure how I did this, I think I had still access to the raw stats
back then. I suppose we can add this calculation too somehow now Andrew has
improved it so much.

Because it makes no real sense to stall the Jenkins project forever for
users that don't upgrade anyways.


Le sam. 4 déc. 2021 à 23:02, Tim Jacomb  a écrit :

> Looks like Andrew has fixed the reporting issue for core versions by
> rewriting the processor:
> https://github.com/jenkins-infra/jenkins-usage-stats
>
> You can see the report at
> https://stats.jenkins.io/plugin-installation-trend/jvms.json
>
> Last month:
>
>
>"163572480": {
> "1.7": 686,
> "1.8": 207812,
> "10": 39,
> "11": 80015,
> "12": 53,
> "13": 71,
> "14": 81,
> "15": 139,
> "16": 35,
> "17": 111,
> "9": 23
>
>
> On Thu, 18 Nov 2021 at 18:29, 'Jesse Glick' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> On Thu, Nov 18, 2021 at 4:57 AM 'Daniel Beck' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> On Thu, Nov 18, 2021 at 10:22 AM 'Björn Pedersen' via Jenkins Developers
>>>  wrote:
>>>
 you can build projects in any java version you like, even if  jenkins
 is running in another version.

>>>
>>> Unless you use https://plugins.jenkins.io/maven-plugin/
>>>
>>
>> Even then it is OK so long as your agent *can* run the version of Java
>> required by Jenkins. You can still build projects with `-release 8` or
>> whatever. You can also use forked versions of JDK tools like `javac`, and
>> `java` for Surefire tests; the plugin will actually set this up for you
>> automatically if you pick an older JDK for the project, because we have
>> been here before.
>>
>> (which you shouldn't, because it's terrible)
>>>
>>
>> That too.
>>
>> --
>> 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/CANfRfr2AgR%2BS0v2ThYh%2BabFLR1nv0A-EHgy9u78tZ1BWr7G4GA%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidkHww6fRubiWi6A3ZYRLpMwABBNwWM9%3DzSJTS02BmhVQ%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/CANWgJS5XJx6i1oPaTe8xz5z%2B3KyTQdu15_9DvHLCaiAgjhf%3Dvg%40mail.gmail.com.

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

[Baptiste Mathus]

Agreed that the benefit to developers is a critical point. For Java 8 bump

that was a big driver. We do want Jenkins to be appealing to the OSS Java
developers out there.

I think we should plan & announce ahead like we've done for Java 8 [1]

[2]

[3] 
 [4]
,
like saying we'll bump to Java 11 as min version some time in (late?) 2022,
blog about it etc.




Le mer. 17 nov. 2021 à 14:39, 'Jesse Glick' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

> On Wed, Nov 17, 2021 at 4:03 AM 'Daniel Beck' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> […] do not show a rapid growth of Java 11 adoption
>>
>>
> Every time this topic comes up I need to remind people that while the
> proportion of installations currently running 8 vs. 11 is an interesting
> datum, it is not particularly useful for making a decision about when to
> drop support for 8. So long as you *can* run Jenkins on 8, and you were
> doing so before, and 8 is still receiving security fixes, and there is no
> particular functionality which is only available on 11 or even runs better
> in any way that I am aware of, why would you bother to even take five
> minutes to switch to a different Java version?
>
> What needs to be weighed is on the one hand the advantage to Jenkins
> *developers* in requiring 11 (as Tim describes); and on the other hand
> the proportion of Jenkins administrators who would *refuse* to upgrade
> Jenkins if it meant switching to 11 (for example because of some dumb
> enterprise policy, or because of lack of support for agents on exotic
> platforms).
>
> --
> 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%3D2tCML%2BOYBgXmrmX2SD4_oxGDgL%2B7Fv_28S5hod9bHg%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/CANWgJS4Pg-_z-Oh41JAcnrZvBP-3XdrAnouMSpy5V35BGWpn-w%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Baptiste Mathus]

Just implemented the RPU teams part. Open for feedback
https://github.com/jenkins-infra/repository-permissions-updater/pull/2154

Le mer. 27 oct. 2021 à 11:50, Tim Jacomb  a écrit :

> Sounds fine, not 100% sure company needs to be at the start but we can
> also rationalise it later if we get more
>
> On Wed, 27 Oct 2021 at 10:42, Baptiste Mathus  wrote:
>
>> Hi all,
>>
>> FYI I've created this epic to track this:
>> https://issues.jenkins.io/browse/INFRA-3111.
>>
>> I plan to manually do the creation of a GitHub team for CloudBees
>> developers in the next hour or so if nobody objects. AFAICT from the
>> discussion above, we have an agreement that it makes sense and is
>> acceptable.
>> I will name it "company-cloudbees-developers" so one can easily find all
>> companies in the teams, using typically
>> https://github.com/orgs/jenkinsci/teams?query=company-
>>
>> For the RPU part, I've created
>> https://issues.jenkins.io/browse/INFRA-3113 to describe what we'd want
>> to have.
>> We (cloudbees team) plan to look into implementing this soon. Given this
>> sounds reasonably simple, I think it can be done some time in November 2021.
>> Any review on this enhancement proposal is welcome :-).
>>
>> Last, and important, thing: this feature is not only for CloudBees. The
>> point is that any company/team willing to do this is welcome to ask.
>>
>> Cheers
>>
>>
>> Le jeu. 21 oct. 2021 à 19:12, 'Daniel Beck' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> a écrit :
>>
>>>
>>>
>>> On Thu, Oct 21, 2021 at 3:47 PM Baptiste Mathus  wrote:
>>>
>>>> Care to elaborate what you mean and how that would work? IIUC, what
>>>> you're describing would quite entail refactoring all existing "xyz-plugin
>>>> developer" groups on GitHub side?
>>>> And as you know we currently have close to no notion of github on RPU
>>>> side, like the names there are only artifactory's ones.
>>>>
>>>
>>> Yup, these realms are independent so unless you find a way to have a
>>> tamper-proof bi-directional mapping, there's no need to worry about GH
>>> permissions while dealing with upload permissions. Note that I only
>>> responded to the part around RPU.
>>>
>>>
>>>>  Do you mean we should improve RPU to better manage multi-modules? In
>>>> that case, I don't disagree, but I think we should put it in a separate
>>>> bucket so we can improve the situation iteratively.
>>>> I think what James describes can be done in a very quick way (still
>>>> clean), and what you describe here seems bigger.
>>>>
>>>
>>> I am just pointing out that the use case goes beyond multiple plugins
>>> maintained by the same group, and this change can also benefit others while
>>> the mentioned limitation exists.
>>>
>>> --
>>> 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/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CANWgJS4prSBQsOx%3D2UmfqrjronEkn7j4qWWQvVk2WaGwS8ZPZA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4prSBQsOx%3D2UmfqrjronEkn7j4qWWQvVk2WaGwS8ZPZA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicz862ZrAAx%2Bbjsb_E_6gTj8NkYk2x%3DNBZQvxNktLye3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicz862ZrAAx%2Bbjsb_E_6gTj8NkYk2x%3DNBZQvxNktLye3w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANWgJS5%3DZLr3TYydkNr4b5N8VBNRVA0TFG%2BRV8tRnAwh-AbwYw%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Baptiste Mathus]

Thanks Tim for the confirmation.

Yeah, not 100% of the naming either.
But yep, given at this point it's only one + this part is manual, that's
not a big deal yet.

Le mer. 27 oct. 2021 à 11:50, Tim Jacomb  a écrit :

> Sounds fine, not 100% sure company needs to be at the start but we can
> also rationalise it later if we get more
>
> On Wed, 27 Oct 2021 at 10:42, Baptiste Mathus  wrote:
>
>> Hi all,
>>
>> FYI I've created this epic to track this:
>> https://issues.jenkins.io/browse/INFRA-3111.
>>
>> I plan to manually do the creation of a GitHub team for CloudBees
>> developers in the next hour or so if nobody objects. AFAICT from the
>> discussion above, we have an agreement that it makes sense and is
>> acceptable.
>> I will name it "company-cloudbees-developers" so one can easily find all
>> companies in the teams, using typically
>> https://github.com/orgs/jenkinsci/teams?query=company-
>>
>> For the RPU part, I've created
>> https://issues.jenkins.io/browse/INFRA-3113 to describe what we'd want
>> to have.
>> We (cloudbees team) plan to look into implementing this soon. Given this
>> sounds reasonably simple, I think it can be done some time in November 2021.
>> Any review on this enhancement proposal is welcome :-).
>>
>> Last, and important, thing: this feature is not only for CloudBees. The
>> point is that any company/team willing to do this is welcome to ask.
>>
>> Cheers
>>
>>
>> Le jeu. 21 oct. 2021 à 19:12, 'Daniel Beck' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> a écrit :
>>
>>>
>>>
>>> On Thu, Oct 21, 2021 at 3:47 PM Baptiste Mathus  wrote:
>>>
>>>> Care to elaborate what you mean and how that would work? IIUC, what
>>>> you're describing would quite entail refactoring all existing "xyz-plugin
>>>> developer" groups on GitHub side?
>>>> And as you know we currently have close to no notion of github on RPU
>>>> side, like the names there are only artifactory's ones.
>>>>
>>>
>>> Yup, these realms are independent so unless you find a way to have a
>>> tamper-proof bi-directional mapping, there's no need to worry about GH
>>> permissions while dealing with upload permissions. Note that I only
>>> responded to the part around RPU.
>>>
>>>
>>>>  Do you mean we should improve RPU to better manage multi-modules? In
>>>> that case, I don't disagree, but I think we should put it in a separate
>>>> bucket so we can improve the situation iteratively.
>>>> I think what James describes can be done in a very quick way (still
>>>> clean), and what you describe here seems bigger.
>>>>
>>>
>>> I am just pointing out that the use case goes beyond multiple plugins
>>> maintained by the same group, and this change can also benefit others while
>>> the mentioned limitation exists.
>>>
>>> --
>>> 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/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CANWgJS4prSBQsOx%3D2UmfqrjronEkn7j4qWWQvVk2WaGwS8ZPZA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4prSBQsOx%3D2UmfqrjronEkn7j4qWWQvVk2WaGwS8ZPZA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicz862ZrAAx%2Bbjsb_E_6gTj8NkYk2x%3DNBZQvxNktLye3w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicz862ZrAAx%2Bbjsb_E_6gTj8NkYk2x%3DNBZQvxNktLye3w%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANWgJS65Zy2D0QDs93zx8yDDGgFfqAycPPUnXdC_QJTBrKJM%3DA%40mail.gmail.com.

Somewhere in the Jenkins community for job offers around Jenkins

[Baptiste Mathus]

Hi all,

This idea has been turning in my head for some time, finally putting it
here.

I think we should have a "place" [1] for companies to be able to post job
offers around Jenkins.

I think this would be a great win-win for the Jenkins Project and the
companies that use it:

   - It would benefit the Jenkins Project by showing that there is a bunch
   of companies out there using Jenkins, and looking for people with skills on
   it. Exposing the vitality of our community.
   - it would benefit companies that use Jenkins to have a place where, by
   definition, they can find a bunch of people who have interest in Jenkins.


WDYT :-) ?

-- Baptiste

[1] Maybe a new ML, maybe a new space in community.jenkins.io.
I think at this point we can leave this question out (for now).
This place IMO has to be separate, so interested folks can opt in and NOT
ever feel spammed by such postings.

-- 
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/CANWgJS5mxGD-eWgkU1C_-DiQFz-HSVrEdWFtt%2BrdFRJW%3DhxCtw%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Baptiste Mathus]

Hi all,

FYI I've created this epic to track this:
https://issues.jenkins.io/browse/INFRA-3111.

I plan to manually do the creation of a GitHub team for CloudBees
developers in the next hour or so if nobody objects. AFAICT from the
discussion above, we have an agreement that it makes sense and is
acceptable.
I will name it "company-cloudbees-developers" so one can easily find all
companies in the teams, using typically
https://github.com/orgs/jenkinsci/teams?query=company-

For the RPU part, I've created https://issues.jenkins.io/browse/INFRA-3113
to describe what we'd want to have.
We (cloudbees team) plan to look into implementing this soon. Given this
sounds reasonably simple, I think it can be done some time in November 2021.
Any review on this enhancement proposal is welcome :-).

Last, and important, thing: this feature is not only for CloudBees. The
point is that any company/team willing to do this is welcome to ask.

Cheers


Le jeu. 21 oct. 2021 à 19:12, 'Daniel Beck' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

>
>
> On Thu, Oct 21, 2021 at 3:47 PM Baptiste Mathus  wrote:
>
>> Care to elaborate what you mean and how that would work? IIUC, what
>> you're describing would quite entail refactoring all existing "xyz-plugin
>> developer" groups on GitHub side?
>> And as you know we currently have close to no notion of github on RPU
>> side, like the names there are only artifactory's ones.
>>
>
> Yup, these realms are independent so unless you find a way to have a
> tamper-proof bi-directional mapping, there's no need to worry about GH
> permissions while dealing with upload permissions. Note that I only
> responded to the part around RPU.
>
>
>>  Do you mean we should improve RPU to better manage multi-modules? In
>> that case, I don't disagree, but I think we should put it in a separate
>> bucket so we can improve the situation iteratively.
>> I think what James describes can be done in a very quick way (still
>> clean), and what you describe here seems bigger.
>>
>
> I am just pointing out that the use case goes beyond multiple plugins
> maintained by the same group, and this change can also benefit others while
> the mentioned limitation exists.
>
> --
> 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/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLs27A9ODjSe537Ar3pRwkTYNiFr8WHX88Kd7EQtvUSow%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANWgJS4prSBQsOx%3D2UmfqrjronEkn7j4qWWQvVk2WaGwS8ZPZA%40mail.gmail.com.

Re: Company plugins in Jenkins org

[Baptiste Mathus]

Le jeu. 21 oct. 2021 à 13:58, 'Daniel Beck' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

>
>
> On Thu, Oct 21, 2021 at 1:47 PM 'jn...@cloudbees.com' via Jenkins
> Developers  wrote:
>
>> Additionally to make RPU easier, we are planning to add support for
>> groups of users so that we would just need to modify a single "group
>> definition file" to update permissions in artifactory.
>>
>
> Sounds great. I would put the permissions declarations in RPU itself
> though, to make this just a layer of abstraction on top of the current
> definitions.
>

Care to elaborate what you mean and how that would work? IIUC, what you're
describing would quite entail refactoring all existing "xyz-plugin
developer" groups on GitHub side?
And as you know we currently have close to no notion of github on RPU side,
like the names there are only artifactory's ones.


>
> Another use case, while RPU has purely artifact-based configuration
> (something I've wanted to change for a while but haven't found the time),
> would be multimodule projects deploying multiple artifacts. You don't need
> to be a company maintaining multiple plugins to have trouble with
> permissions.
>

Do you mean we should improve RPU to better manage multi-modules? In that
case, I don't disagree, but I think we should put it in a separate bucket
so we can improve the situation iteratively.
I think what James describes can be done in a very quick way (still clean),
and what you describe here seems bigger.

Still, I certainly agree it makes sense to define the full & final "desired
state" we want to be in. I _think_ this is what you're talking about Daniel.

-- 
> 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/CAMo7PtLX-wWQXYaX6RAR2DWXzU-_ABEHBNDF%3D7Tu8zNCbWYJKw%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/CANWgJS53HetnKcjS%2BZWRanidi0wL5uDNvh%3De7gUyOu1gbFUb_A%40mail.gmail.com.

Re: Proposal: Move Jenkins Test Harness issue tracker to GitHub Issues

[Baptiste Mathus]

+1 for these repos.

Le mar. 19 oct. 2021 à 08:35, Oleg Nenashev  a
écrit :

> I am +1 too. I switched Jenkins Test Harness taking the feedback.
> Will give it a bit more time for the rest of the repositories
>
> On Monday, October 18, 2021 at 4:12:11 PM UTC+2 timja...@gmail.com wrote:
>
>> +1 to Jesse’s list
>>
>> On Mon, 18 Oct 2021 at 14:33, 'Jesse Glick' via Jenkins Developers <
>> jenkin...@googlegroups.com> wrote:
>>
>>> On Sun, Oct 17, 2021 at 4:50 AM Oleg Nenashev 
>>> wrote:
>>>
 Currently we have only a few issues in Jira

>>>
>>> BTW if switching canonical issue tracker I recommend also closing any
>>> remaining open issues in Jira and refiling them in GitHub (with links in
>>> either direction for reference).
>>>
>>> --
>>>
>> You received this message because you are subscribed to the Google Groups
>>> "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3YMJjyc7RfC4cWV-zUX13yKQhZ0O75h8mK_qDSerTTQw%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/2f2a02d8-2b3b-4b0e-9379-55413aa8da39n%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/CANWgJS53DJDohqJuBRd-bSy93Lmdx54gL1xjq%2B4LUaXmFUaTHw%40mail.gmail.com.

Re: Emeritus concept for Jenkins developers (was: Re: Proposal: Adding Basil Crow to the Jenkins Core maintainers team)

[Baptiste Mathus]

I'm not that much concerned that we wouldn't do exactly what Apache does
TBH. More of an inspiration.

IOW, we could just create a special team with no permission of "emeritus"
members. People in jenkins/core that we know have not been active since 1+
year anywhere.
And when in doubt, we'd double check with these persons, and if they don't
answer we'd move them to this emeritus list.


Baptiste


Le jeu. 23 sept. 2021 à 20:30, Matt Sicker  a écrit :

> At Apache, emeritus status is typically requested by the individual.
> That might be hard to emulate here if some otherwise emeritus members
> of Jenkins aren't here to request emeritus. Some forms of active
> versus inactive members could be useful, though, for code review
> purposes and other bookkeeping.
>
> On Thu, Sep 23, 2021 at 5:08 AM Tim Jacomb  wrote:
> >
> > +1 we have this in jenkins-infra
> >
> > On Thu, 23 Sep 2021 at 10:28, Baptiste Mathus  wrote:
> >>
> >> Hi all,
> >>
> >> Following up on Jesse's comment, and as I was reflecting on this a few
> days ago: I think we should introduce an Emeritus concept/status for
> Jenkins core team's inactive members.
> >>
> >> That would allow "cleaning up" the list for various reasons, while
> still recognizing the contributions of such individuals.
> >>
> >> I think, akin to Apache does in many projects, we should also have a
> straightforward way for such members to be reinstated inthe core list when
> they would request it.
> >>
> >> WDYT?
> >>
> >> Once we agree on this principle, we will also need to dicuss the
> "inactive member" definition, but that's a secondary concern for now IMO.
> >>
> >> Baptiste
> >>
> >> Le mer. 22 sept. 2021 à 14:10, wfoll...@cloudbees.com <
> wfollon...@cloudbees.com> a écrit :
> >>>
> >>> +1 as well, really involved in the community so it's just natural :-)
> >>>
> >>> On Wednesday, September 22, 2021 at 2:05:32 PM UTC+2 Jesse Glick wrote:
> >>>>
> >>>> If he is interested, absolutely +1!
> >>>>
> >>>> By the way there are a number of people in
> https://github.com/orgs/jenkinsci/teams/core/members who are no longer
> active in the Jenkins community and who should likely be removed.
> >>>
> >>> --
> >>> 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/2735a776-6bdf-485c-bdb0-96d45175ab67n%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/CANWgJS5RcWPCSPghkpyBL3TH8iwv96ogjSbunVBbAdQ0rsTh6A%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie4XJNJ_WNDmH%3DJsuid4g5w9X%3D%2B8%3DTn3odWs0gZoZLHhQ%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/CACmp6kpV8vE-8C%3D7mAE3DgcAA3O84Fgyqg0CpXUPCq5-CrZxpw%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/CANWgJS6ReuCQTxfcw52pEYL8PK-mB8rXdREAe5uywrwT%2B6HCCA%40mail.gmail.com.

Emeritus concept for Jenkins developers (was: Re: Proposal: Adding Basil Crow to the Jenkins Core maintainers team)

[Baptiste Mathus]

Hi all,

Following up on Jesse's comment, and as I was reflecting on this a few days
ago: I think we should introduce an Emeritus concept/status for Jenkins
core team's inactive members.

That would allow "cleaning up" the list for various reasons, while still
recognizing the contributions of such individuals.

I think, akin to Apache does in many projects, we should also have a
straightforward way for such members to be reinstated inthe core list when
they would request it.

WDYT?

Once we agree on this principle, we will also need to dicuss the "inactive
member" definition, but that's a secondary concern for now IMO.

Baptiste

Le mer. 22 sept. 2021 à 14:10, wfoll...@cloudbees.com <
wfollon...@cloudbees.com> a écrit :

> +1 as well, really involved in the community so it's just natural :-)
>
> On Wednesday, September 22, 2021 at 2:05:32 PM UTC+2 Jesse Glick wrote:
>
>> If he is interested, absolutely +1!
>>
>> By the way there are a number of people in
>> https://github.com/orgs/jenkinsci/teams/core/members who are no longer
>> active in the Jenkins community and who should likely be removed.
>>
> --
> 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/2735a776-6bdf-485c-bdb0-96d45175ab67n%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/CANWgJS5RcWPCSPghkpyBL3TH8iwv96ogjSbunVBbAdQ0rsTh6A%40mail.gmail.com.

Re: Proposal: Adding Basil Crow to the Jenkins Core maintainers team

[Baptiste Mathus]

+1. IMO Basil is wa past the minimum criteria to get this status.

Le mer. 22 sept. 2021 à 11:14, Oleg Nenashev  a
écrit :

> Dear all,
>
> Basil has been a very active contributor to the Jenkins core since 2020,
> and he has contributed a lot to Jenkins over the past several years. He is
> an active community member, and he helps a lot with the technical debt
> cleanup and code reviews in Jenkins.
>
> It would be great to have Basil joining the Jenkins core maintainers team.
> I propose to officially add Basil to the Jenkins core team. IMHO the code
> reviewer stage can be skipped, because he has been already contributing a
> lot to the reviews. Opinions/votes?
>
> References:
>
>- https://github.com/basil
>- Jenkins core maintainers team and ladder:
>https://github.com/jenkinsci/jenkins/blob/master/docs/MAINTAINERS.adoc#team
>
> Best regards,
> Oleg Nenashev
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/0c920f79-f7b7-4299-92d7-15a814821632n%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/CANWgJS55rBhwXNumbJL2rLRa1cc4h%2BpjLgiM00n%2BByBLsxf9fw%40mail.gmail.com.

Re: LTS backporting policy

[Baptiste Mathus]

Right, re-reading this part well (thanks Tim), I think this should be
enough indeed?
Not fully sure about the term "fix" being too precise, or vague :), but
probably that's nitpicking.

WDYT James, do you feel making a more precise note around "dependency
update with known CVE" or so would still be important for some reason?

Thanks

Le jeu. 2 sept. 2021 à 12:18, Tim Jacomb  a écrit :

> This is already covered as far as I can tell:
>
> https://www.jenkins.io/download/lts/#backporting-process
> > Aside from the model set out above, backporters apply some subjective
> selection — for example whether a fix is easy and safe to backport,
> confidence in the fix, importance/impact of the problem, how much time is
> left until the end of backporting window and so on.
>
> We have already been back-porting some dependency updates (e.g. xstream),
> as security scanners pick them up even though we know we aren't vulnerable.
>
> Do you think that's enough? Or some more specific wording on that page?
>
> Thanks
> Tim
>
>
>
> On Wed, 1 Sept 2021 at 15:48, jn...@cloudbees.com 
> wrote:
>
>> Sure,
>>
>> I was just asking it to be added to the list of eligible criteria.  As
>> with any bug that is also eligible there is a decision to be made as to if
>> we are to cherry-pick the change or not.
>>
>> (on a randomly different note - if we where actually vulnerable - we
>> would not have this luxury!)
>>
>> /James
>>
>>
>>
>> On Wednesday, September 1, 2021 at 3:36:05 PM UTC+1 Oleg Nenashev wrote:
>>
>>> I am +0.5, but being eligible does not immediately mean the change would
>>> be backported. Dependency updates may also introduce regressions. As any
>>> other backport, risks need to be evaluated. IMHO it should be up for
>>> backporting requesters to prove the safety of changes and to ensure there
>>> is enough soak testing and test coverage. Same for any other non-critical
>>> backport
>>>
>>> On Tuesday, August 31, 2021 at 8:16:08 PM UTC+2 boa...@gmail.com wrote:
>>>
 Are there specific libraries we can list for safe upgrades? Like
 XStream, Jackson, Commons, etc, for common upgrades. I wouldn’t be super
 comfortable with a blanket policy, but for all our more stable ones, I
 think it’s a good idea.

 Matt Sicker

 On Aug 31, 2021, at 09:01, wfoll...@cloudbees.com <
 wfoll...@cloudbees.com> wrote:

 Totally agree. Especially when the update is not a major bump of 3
 versions. Most of the time it's just a minor/bug version bump.

 That will greatly help on the security scanners area, where the "fear"
 dominates the market :-)

 Thanks James for the suggestion, great idea.

 Wadeck

 On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 jn...@cloudbees.com
 wrote:

> Hi all,
>
> I would like to propose that we add to the list of eligible criteria
> for backporting the following
>
> * is a dependency update with a known security issue
>
> The reason for this if we have a dependency with a security issue that
> is exploitable from Jenkins we already do include that as a LTS issue via
> the current SECURITY process, however if the issue is *not*
> exploitable then we do not. (for example the recent XStream issues have 
> not
> impacts Jenkins as we already use an allow list).
>
> However as supply chain issues are becoming more prominent to our
> users, they are scanning software with automated tools that look at the
> dependencies, and these scanners do not understand how a library is used
> or  configured, and has the potential to:
>
> * make the software look insecure (thus be a barrier to adoption)
> or
> * cause extra nose asking about CVE-2021-123456
>
> WDYT?
>
> /James
>
 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%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/bad90cc0-1307-4184-9d3f-2a6a27345ddan%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the 

Re: Hosting

[Baptiste Mathus]

I am ready to help again on hosting.

Similar to how Gavin phrased it, I'll help move tickets through the pipe.

Cheers

Le jeu. 26 août 2021 à 08:23, Tim Jacomb  a écrit :

> You can just click leave team
>
> On Wed, 25 Aug 2021 at 22:33, Slide  wrote:
>
>> I should probably be removed from that team as well.
>>
>> On Wed, Aug 25, 2021 at 1:18 PM Tim Jacomb  wrote:
>>
>>> Oleg has permissions on the team or Olivier:
>>> https://github.com/orgs/jenkins-infra/teams/hosting/members
>>>
>>>
>>> On Wed, 25 Aug 2021 at 21:03, Slide  wrote:
>>>
 Those are the basics, just the bot checker (jenkins-admin: check
 HOSTING-) in the jenkins-hosting channel.

 On Wed, Aug 25, 2021 at 12:20 PM 'Gavin Mogan' via Jenkins Developers <
 jenkinsci-dev@googlegroups.com> wrote:

> Okay, making it official. If nobody else speaks up as wanting to take
> over as lead before end of week (Friday night pacific time) I'll take over
> and make sure hosting requests get moving.
>
> I think i've fixed my irc client so I should stay in the channels now.
> Can I get invited to the hosting github teams as well?
>
> Is there anything else that might be needed for transition?
>
> Gavin
>
> On Wed, Aug 25, 2021 at 8:07 AM wfoll...@cloudbees.com <
> wfollon...@cloudbees.com> wrote:
>
>> Thank you very much Alex for the effort you invested on this area.
>> This is a really important piece of the process for the security
>> perspective. The fact that you did the preliminary security checks and if
>> something was weird, to ask the security team to make a more complete
>> audit, was of a great help for us.
>>
>> I cannot ask you Gavin to do more than what you are proposing to do
>> as if you are not proposing this it will be mainly nothing being done, so
>> anything is better than nothing :-) In the case where you are not sure
>> about a plugin, if you are seeing something weird, do not hesitate to 
>> ping
>> Daniel Beck and me in the HOSTING ticket, requesting an audit from us.
>>
>> Wadeck
>>
>> On Wednesday, August 25, 2021 at 5:58:20 AM UTC+2
>> ga...@gavinmogan.com wrote:
>>
>>> If nobody else is able to step up, I can take it, but I won't be
>>> code reviewing and as quickly as possible switch it from jira+irc to
>>> https://github.com/jenkins-infra/repository-permissions-updater +
>>> issue bot
>>> All i'll be doing is "Is there another plugin that sounds similar?
>>> Does it pass the checks? approved"
>>>
>>>
>>> On Tue, Aug 24, 2021 at 8:21 PM Slide  wrote:
>>>
 Hi Everyone,

 I sent the group an email a while back about not having time for
 managing hosting requests and was looking for someone to step up and 
 take
 it over. That hasn't really happened and I am at a point now where I 
 can no
 longer do it at all. Someone from the community will need to step up 
 and
 take this over ASAP. I am willing to walk someone through stuff, but I
 can't monitor the hosting Jira and do the checks and code reviews 
 anymore.

 Regards,

 Alex

 --
 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-de...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVcc_XM8KO7XAxE7bBgvxeH3b6McLD-fVMi0AV9dCRvKOQ%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/9b9ee1d8-2f3a-41b3-8107-ee6add773ca7n%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/CAG%3D_DutKi%2Bazg5WS%3DW6%2BBZ5zH0fox1AhHUXbJn93H0KtJEWgbw%40mail.gmail.com

Re: Choosing Jenkins September LTS release baseline

[Baptiste Mathus]

2.303 testing was fine and revealed no further issues than on 2.302.

(Thanks Beatriz for driving this testing!)

Le mer. 11 août 2021 à 10:44, Baptiste Mathus  a écrit :

> I agree the diff seems reasonably small between 2.302 and 2.303.
> Still, we are re-running our CloudBees testsuite on the 2.303 to assess
> the impact, if any. Stay tuned.
>
> Le mer. 11 août 2021 à 10:09, Tim Jacomb  a écrit :
>
>> I think we can switch the baseline to newer? Either way I think it's fine
>> to include the above change.
>>
>> On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:
>>
>>> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck 
>>> wrote:
>>> > Core dependency version number semantics means anyone on a weekly
>>> release after the LTS baseline but before the change made it into core
>>> regularly, will not have that API and plugins will fail while appearing
>>> compatible.
>>>
>>> Ah right, I hadn't considered that.
>>>
>>> > Given that only dependency updates went into 2.303, there's also an
>>> argument for us to choose that as the new baseline instead of 2.302;
>>> eliminating the above problem entirely without adding a lot of risk through
>>> unproven changes (I would expect commons-compress and spring-security
>>> updates to be safe enough).
>>>
>>> If it isn't too late to switch to 2.303, that sounds ideal to me. I
>>> can easily update the BOM line. But I don't feel strongly either way.
>>>
>>> --
>>> 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/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.com
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/CANWgJS6rhz-5pXxxbZnG2MREMeut3mZ_Y3%2BasMwCUNckvj2N_w%40mail.gmail.com.

Re: Choosing Jenkins September LTS release baseline

[Baptiste Mathus]

I agree the diff seems reasonably small between 2.302 and 2.303.
Still, we are re-running our CloudBees testsuite on the 2.303 to assess the
impact, if any. Stay tuned.

Le mer. 11 août 2021 à 10:09, Tim Jacomb  a écrit :

> I think we can switch the baseline to newer? Either way I think it's fine
> to include the above change.
>
> On Wed, 11 Aug 2021 at 08:00, Basil Crow  wrote:
>
>> On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck  wrote:
>> > Core dependency version number semantics means anyone on a weekly
>> release after the LTS baseline but before the change made it into core
>> regularly, will not have that API and plugins will fail while appearing
>> compatible.
>>
>> Ah right, I hadn't considered that.
>>
>> > Given that only dependency updates went into 2.303, there's also an
>> argument for us to choose that as the new baseline instead of 2.302;
>> eliminating the above problem entirely without adding a lot of risk through
>> unproven changes (I would expect commons-compress and spring-security
>> updates to be safe enough).
>>
>> If it isn't too late to switch to 2.303, that sounds ideal to me. I
>> can easily update the BOM line. But I don't feel strongly either way.
>>
>> --
>> 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/CAFwNDjoS1MQP3LzjcXDkETPc9MjoMv10yd6ZLKcPekZsawNcDA%40mail.gmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidRD5GC1cv%2BPzkcZJ%3DSVwxf93%2B%2B7_ckGWRCQb12y-K2_A%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/CANWgJS5TxKmHxsmjOg_HD7sfJ8LJ1%3DGkwsW_TWOHn7V4K7qnfA%40mail.gmail.com.

Re: Jenkins 2.289.3 LTS RC testing started

[Baptiste Mathus]

I see the same as you from the phone Mark.

Le ven. 16 juil. 2021 à 17:50, Mark Waite  a
écrit :

> I wasn't able to download the release candidate from
> https://repo.jenkins-ci.org/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT/jenkins-war-2.289.3-20210716.091232-1.war
> with wget or curl or my web browser.  They all replied with a JSON file
> that contained the text "404".
>
> I was able to download if I open a web browser to
> https://repo.jenkins-ci.org/ui/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT
> and then click the jenkins-war-2.289.3 hyperlink.
>
> I don't understand the difference between those two download methods.  My
> Windows based web browser is somehow smarter than my Linux command line
> utilities.
>
> Have others seen the same issue?
>
> On Fri, Jul 16, 2021 at 3:20 AM Ildefonso Montero 
> wrote:
>
>> Hello everyone,
>>
>> Latest LTS RC was made public and it is ready to be tested. The final
>> release is scheduled for 2021-07-28.
>>
>> Please, report your findings in this thread.
>>
>> Download the release from
>> https://repo.jenkins-ci.org/native/snapshots/org/jenkins-ci/main/jenkins-war/2.289.3-SNAPSHOT/jenkins-war-2.289.3-20210716.091232-1.war
>>
>> Thanks!
>>
>> --
>>
>> Ildefonso Montero Pérez
>> Senior Software Engineer
>>
>> CloudBees, Inc
>>
>>
>>
>> E: imont...@cloudbees.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/CA%2BUGhi_FjZ-ahDo79M11QxXEo-PgPc-tKxX04hUeKLx5oF4ZSg%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/CAO49JtEyq0vOSX7pgQFirqOfa_9STdbuLj38ZM2ZBcQ-LAPJZw%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/CANWgJS6DJfXHkJnOgcSEpuBbg%2BxyB8AMBUF1Er79hYrOK0afKg%40mail.gmail.com.

Re: Join docker packaging team

[Baptiste Mathus]

+1 obviously

Le sam. 3 juil. 2021 à 06:45, Oleg Nenashev  a
écrit :

> +1
>
> On Friday, July 2, 2021 at 2:50:20 PM UTC+2 Mark Waite wrote:
>
>> +1 from me to make Tim one of the maintainers of the Docker images.
>>
>> On Fri, Jul 2, 2021 at 6:46 AM Tim Jacomb  wrote:
>>
>>> Hello
>>>
>>> I'm doing some work on multi arch builds for the controller docker image.
>>> (see https://github.com/jenkinsci/docker/pull/1137)
>>>
>>> Also working on speeding up the build to go with this.
>>>
>>> In order to make some of these changes I'll need to make changes to the
>>> Jenkinsfile.
>>>
>>> I would like to request commit access to help with this.
>>>
>>> I don't want to commit to any long term maintenance but I _may_ help out
>>> where I can.
>>>
>>> Thanks
>>> Tim
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-de...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bie36o%3D1-dT5p2Livz5Wmr6CeWQh0-oDNOK9JAb4emckUQ%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/cf765322-5dcd-45f3-89d6-a2d832c9b09fn%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/CANWgJS4gY1J5YW4J%3DcyreO3KgRjKiGHSpk8DsCD8PoZFWrqZkA%40mail.gmail.com.

Re: HELP NEEDED - Jenkins contributor summit on Jun 25

[Baptiste Mathus]

I'm sorry to be so late on this... I am going to write here for visibility,
and I'll also add or see to add it correctly the sheet initiated by Oleg.

1. I would like to help facilitate a conversation on Guava upgrade in
Jenkins Core.
As you know, this work is already somehow started. I'd like us to take the
summit opportunity to decide on next steps, approaches.
Our team at CloudBees is committed to help on this subject.

2. Plugin EOL policy // plugin maintenance status
I think these two subjects would serve us as a community to keep moving
Jenkins forward.
For the commons-digester:2.1 recent removal for instance, I think we spent
a subtantial amount of effort on plugins nobody should use anymore since a
long time.
If we had had such a policy, we could have saved a lot of energy together.

3. Company/team ownership for plugins
As an ex-HOSTING team member and a contributor since a few years, I think
we need to have a clearer stance for companies to implement a Jenkins
plugin for their software.
It happens regularly than a company, not intimate with the Jenkins
Project's governance, will request commit access to a plugin they think
they own somehow. (e.g. HOSTING-901, HOSTING-346, HOSTING-288, HOSTING-134,
and we could go on)
Only then they discover that from the Jenkins Project's standpoint, they do
not *exist*. An ex-employee that may have even left a given company could
disagree to let commit rights go and they would be entitled to this
(fortunately didn't happen yet, to my knowledge).

The other case I've got in mind is the "team" concept. That's the one I'm
most interested in personally. For example, when people move between teams
in our company etc., we usually need to update many files in RPU and
request commit access in various repositories.
If we could have an official concept for teams within the Jenkins Project,
I think we could set up special GH teams (for example one for ours at
CloudBees) + create possibly such a concept for it inside RPU to define
this only once.
I think this is already doable (we already have the core team within GH
e.g.), and we could request an ad-hoc implementation and move on. But I
think there's merit in defining something generalized for the Jenkins
Project's governance.

Thanks for reading :). I definitely didn't plan to send such a long email.

Have a great weeked everyone.

Le jeu. 10 juin 2021 à 14:27, Kara de la Marck  a
écrit :

> Thanks for your suggestion, Oleg!
>
> It's likely better for us to keep all the updates together for the
> Contributors Summit, that way they will be easier to consume for all
> interested parties.
>
> Would it be possible for a contributor who can't make it on the 25th to
> record an update on behalf of a SIG or track?  And that this pre-recorded
> update would be shown during the allocated time on the 25th?
>
>
> On Thu, Jun 10, 2021 at 2:03 AM Oleg Nenashev 
> wrote:
>
>> Hi Kara,
>>
>> Thanks for the feedback and for helping with the Cloud Native SIG! I
>> understand the timezones are imperfect. Apart from moving a meeting to an
>> earlier slot, we have an option to do the Cloud Native SIG meeting on
>> Saturday, Jun 26.
>>
>> I can host meetings if they are after 4AM UTC. Maybe Rick or Himandri
>> would be also available.
>>
>> BR, Oleg
>>
>>
>> On Wed, Jun 9, 2021, 21:50 Kara de la Marck 
>> wrote:
>>
>>> Hi all,
>>>
>>> Thank you for organizing the Contributor Summit and its schedule, Oleg
>>> and Olivier.
>>>
>>> I'm very happy to lead on the Cloud Native track to ensure that we have
>>> a speaker to summarize recent highlights in the Cloud Native SIG; ideally,
>>> this would be an active community member.
>>>
>>> Please note that the time as currently scheduled will be too late for
>>> our Cloud Native SIG participants and contributors in India (and APAC
>>> generally).
>>>
>>>
>>>
>>> On Wed, Jun 9, 2021 at 11:48 AM 'Olblak' via Jenkins Developers <
>>> jenkinsci-dev@googlegroups.com> wrote:
>>>
 Thanks, Oleg for driving this.

 Yesterday, Mark suggested to me to move the contributor track as early
 as possible to have as many people from AMER and EMEA in an interactive
 session.
 This an idea that I like very much and I would like to discuss it
 tomorrow.
 So we would have "project update", "contributor track", "SIG update",
 "CDF project collaboration" as I am suggesting in the google sheet.



 On Wed, Jun 9, 2021, at 6:45 AM, Oleg Nenashev wrote:

 Thanks to Olivier for the contributions and willing to help! Based on
 the feedback in the voting poll, I created a meeting on Thursday, 1PM UTC.
 At this meeting we will agree on the agenda and split the
 organization/moderation tasks. Everyone is welcome to participate, and I
 will also try to record this meeting.

 Links:

 * [Calendar Link](
 

Re: requesting access to blueocean-maven-plugin

[Baptiste Mathus]

I just gave you write access manually from the GH UI Olivier, given you're
already declared in the RPU repo as releaser.

(I've requested voice access on IRC@Libera. Once I get it, I'll redo this
properly from there to have the team created for this repo as usual by the
tooling -- none right now)

Le ven. 4 juin 2021 à 10:25, Olivier Lamy  a écrit :

> Hi
> While upgrading some stuff for blueocean, I figure out I don't have access
> to commit to https://github.com/jenkinsci/blueocean-maven-plugin
> whereas I can deploy release.
>
> Is it possible to have commit access?
>
>
> cheers
> --
> Olivier
>
> --
> 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/CAPoyBqT1n%3Doi944%3DwDDiffuZwARYuJgmfZDGBmisBVa%2BEbjOQg%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/CANWgJS4%2Bzb2Q_710uriz%3DdyJj2ufNqgvLKdutWuNTGxAEtPxRQ%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

FYI all.
The Core PR got merged.

Blog entry PR up for review
https://github.com/jenkins-infra/jenkins.io/pull/4395

I think we should land this blog article asap, so people can start seeing
this today to prepare for upcoming weekly.

-- Baptiste

Le mer. 2 juin 2021 à 01:00, Oleg Nenashev  a
écrit :

> Thanks a lot!
>
> > Then next is 6 years ago. Not holding my breath for these :-).
>
> Me neither. We need Basil's plugin EOL work to land
>
> > I'd like to declare the Digester PR ready-for-merge given the existing
> approvals.
>
> Fine with me. The weekly release is out, so it gives maintainers (if any)
> one extra week to react until next Tuesday. Should be ok. I will initiate
> the contdown
>
> > I don't think however we should block the Digester work until it's done.
> This is something I'd like to help deliver for the next weeks & months so
> we can use it for Guava.
>
> Yes, I agree with not blocking any pending efforts.
>
> Best regards,
> Oleg
>
> On Wed, Jun 2, 2021 at 12:47 AM Baptiste Mathus  wrote:
>
>> Email thread pinging last maintainers' emails taken from git log just
>> sent, see the other thread.
>>
>> Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :
>>
>>>
>>>
>>> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
>>> écrit :
>>>
>>>>
>>>> > I am not sure exactly sure what you mean by this, but I am certainly
>>>> not requesting nor expecting you to support any fallout of this PR. Our
>>>> team will obviously step up if something bad arises
>>>>
>>>> Sorry for confusion, I have no doubt that your team will provide good
>>>> support for this change. What I meant is that I am not ready to put my +1
>>>> for merging, but I do not block others from proceeding with the merge.
>>>>
>>>> > What I'm trying to avoid here is stalling this work. We created this
>>>> PR on the 1st of March.
>>>>
>>>> I do not want to stall it either. This is a good technical debt
>>>> reduction work, and " I definitely do not want the PR to miss the LTS merge
>>>> window" like stated above. I'd love to see it in the September LTS release.
>>>> We are also interested to get it in weekly rather sooner than later so that
>>>> we can address any regressions if reported.
>>>>
>>>>
>>>> >> and do the better effort in reaching out to plugin maintainers and
>>>> getting releases or explicit up-for-adoption where possible.
>>>> > Care to elaborate please? IIUC you mean sending an email to the last
>>>> known maintainers for plugins that are going to be broken when we merge the
>>>> Core PR.
>>>>
>>>> Yes, I mean sending emails offering to either merge/release the fix or
>>>> to put the plugin for adoption. It would be great to finalize Basil's
>>>> plugin EOL JEP so that we have this process more or less automated. But now
>>>> yes, emails. They can be retrieved from the plugin metadata, Jira or Git
>>>> commit history. I can help with these emails as a board member.
>>>>
>>>
>>> OK, I'll do it. I don't plan to wait for their answers though TBH.
>>> I'd like to declare the Digester PR ready-for-merge given the existing
>>> approvals.
>>>
>>> For all still unreleased plugins:
>>> * For teamconcert, seems there's an active maintainer looking into it.
>>> * Then genexus was active last year around early 2020. So I think we
>>> could hope for some answer.
>>> * Then the next unreleased one is config-rotator, last active 4 years
>>> ago. Then next is 6 years ago. Not holding my breath for these :-).
>>>
>>>
>>>
>>>> > TBH after this, I fear a bit the Guava upgrade that we want to help
>>>> on next...
>>>>
>>>> Topic for a contributor summit? I also expect difficulties with Guava
>>>> upgrade and then Groovy update needed for Java 17 and housekeeping.
>>>> Contributor summit could be a good venue to develop strategy for such
>>>> massively used components.
>>>>
>>>
>>> Good idea. I'll raise it with the team.
>>>
>>>
>>>> > What, specifically, is the threshold of usage that would cause you to
>>>> express concern?
>>>>
>>>> I do not have a specific threshold at the moment. And I do not think
>>>> the installation numbers represent the community importance wel

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Email thread pinging last maintainers' emails taken from git log just sent,
see the other thread.

Le mer. 2 juin 2021 à 00:05, Baptiste Mathus  a écrit :

>
>
> Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
> écrit :
>
>>
>> > I am not sure exactly sure what you mean by this, but I am certainly
>> not requesting nor expecting you to support any fallout of this PR. Our
>> team will obviously step up if something bad arises
>>
>> Sorry for confusion, I have no doubt that your team will provide good
>> support for this change. What I meant is that I am not ready to put my +1
>> for merging, but I do not block others from proceeding with the merge.
>>
>> > What I'm trying to avoid here is stalling this work. We created this PR
>> on the 1st of March.
>>
>> I do not want to stall it either. This is a good technical debt reduction
>> work, and " I definitely do not want the PR to miss the LTS merge window"
>> like stated above. I'd love to see it in the September LTS release. We are
>> also interested to get it in weekly rather sooner than later so that we can
>> address any regressions if reported.
>>
>>
>> >> and do the better effort in reaching out to plugin maintainers and
>> getting releases or explicit up-for-adoption where possible.
>> > Care to elaborate please? IIUC you mean sending an email to the last
>> known maintainers for plugins that are going to be broken when we merge the
>> Core PR.
>>
>> Yes, I mean sending emails offering to either merge/release the fix or to
>> put the plugin for adoption. It would be great to finalize Basil's plugin
>> EOL JEP so that we have this process more or less automated. But now yes,
>> emails. They can be retrieved from the plugin metadata, Jira or Git commit
>> history. I can help with these emails as a board member.
>>
>
> OK, I'll do it. I don't plan to wait for their answers though TBH.
> I'd like to declare the Digester PR ready-for-merge given the existing
> approvals.
>
> For all still unreleased plugins:
> * For teamconcert, seems there's an active maintainer looking into it.
> * Then genexus was active last year around early 2020. So I think we could
> hope for some answer.
> * Then the next unreleased one is config-rotator, last active 4 years ago.
> Then next is 6 years ago. Not holding my breath for these :-).
>
>
>
>> > TBH after this, I fear a bit the Guava upgrade that we want to help on
>> next...
>>
>> Topic for a contributor summit? I also expect difficulties with Guava
>> upgrade and then Groovy update needed for Java 17 and housekeeping.
>> Contributor summit could be a good venue to develop strategy for such
>> massively used components.
>>
>
> Good idea. I'll raise it with the team.
>
>
>> > What, specifically, is the threshold of usage that would cause you to
>> express concern?
>>
>> I do not have a specific threshold at the moment. And I do not think the
>> installation numbers represent the community importance well. Big Jenkins
>> setups at enterprises tend to use "exotic" plugins with low installation
>> numbers, just because they have specific requirements to their environment
>> and scalability. Admins of these instances also tend to disable sending
>> usage stats when they discover this option. So I just use personal
>> expertise which might be biased due to my Hardware/Embedded background. Ask
>> Daniel or Jesse how often they do a facepalm after hearing about my
>> use-cases and hacks :)
>>
>> Speaking seriously, we could definitely think about defining our criteria
>> about what we care during such upgrades. Stale plugins and plugins waiting
>> for adoption for years should not be a blocker for changes we need as the
>> community.
>>
>
> I like and support this idea.
> I don't think however we should block the Digester work until it's done.
> This is something I'd like to help deliver for the next weeks & months so
> we can use it for Guava.
>
>
>>
>>
>> On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:
>>
>>> Dear Oleg,
>>>
>>> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev 
>>> wrote:
>>> > I have commented about the plugins removal in another thread.
>>>
>>> In particular, you wrote: "From the list, I am particularly concerned
>>> about Code Coverage plugins which seemed to be actively used."
>>>
>>> You expressed concern about Emma, a code coverage plugin with 3,148
>>> installations. You did not 

[Digester/ACTION REQUIRED] Release needed for plugins: teamconcert, vs-code-metrics, BlameSubversion, javatest-report, vss, genexus, synergy, config-rotator, harvest, cmvc to avoid them to break

[Baptiste Mathus]

Hi,

(in CC the Jenkins developers ML)

You're receiving this email because your email appeared in "git log" for
one of the Jenkins plugins listed in the email subject.
This plugin is *going to start breaking with next Jenkins weekly without an
action*.

If you still consider yourself a maintainer of this plugin, please keep
reading and better yet answer this thread.
If not, you can either tell us this plugin is up for adoption, or ignore.


See https://github.com/jenkinsci/jenkins/pull/5320 for the PR for each
plugin.

Each PR needs to be merged AND released.

Thank you

-- Baptiste

-- 
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/CANWgJS4DREUC_33KJFXkpEYb%2BhpBqORne%2B%2BTjK%3DQW_9wmrQ%3D-w%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Le mar. 1 juin 2021 à 08:48, Oleg Nenashev  a
écrit :

>
> > I am not sure exactly sure what you mean by this, but I am certainly not
> requesting nor expecting you to support any fallout of this PR. Our team
> will obviously step up if something bad arises
>
> Sorry for confusion, I have no doubt that your team will provide good
> support for this change. What I meant is that I am not ready to put my +1
> for merging, but I do not block others from proceeding with the merge.
>
> > What I'm trying to avoid here is stalling this work. We created this PR
> on the 1st of March.
>
> I do not want to stall it either. This is a good technical debt reduction
> work, and " I definitely do not want the PR to miss the LTS merge window"
> like stated above. I'd love to see it in the September LTS release. We are
> also interested to get it in weekly rather sooner than later so that we can
> address any regressions if reported.
>
>
> >> and do the better effort in reaching out to plugin maintainers and
> getting releases or explicit up-for-adoption where possible.
> > Care to elaborate please? IIUC you mean sending an email to the last
> known maintainers for plugins that are going to be broken when we merge the
> Core PR.
>
> Yes, I mean sending emails offering to either merge/release the fix or to
> put the plugin for adoption. It would be great to finalize Basil's plugin
> EOL JEP so that we have this process more or less automated. But now yes,
> emails. They can be retrieved from the plugin metadata, Jira or Git commit
> history. I can help with these emails as a board member.
>

OK, I'll do it. I don't plan to wait for their answers though TBH.
I'd like to declare the Digester PR ready-for-merge given the existing
approvals.

For all still unreleased plugins:
* For teamconcert, seems there's an active maintainer looking into it.
* Then genexus was active last year around early 2020. So I think we could
hope for some answer.
* Then the next unreleased one is config-rotator, last active 4 years ago.
Then next is 6 years ago. Not holding my breath for these :-).



> > TBH after this, I fear a bit the Guava upgrade that we want to help on
> next...
>
> Topic for a contributor summit? I also expect difficulties with Guava
> upgrade and then Groovy update needed for Java 17 and housekeeping.
> Contributor summit could be a good venue to develop strategy for such
> massively used components.
>

Good idea. I'll raise it with the team.


> > What, specifically, is the threshold of usage that would cause you to
> express concern?
>
> I do not have a specific threshold at the moment. And I do not think the
> installation numbers represent the community importance well. Big Jenkins
> setups at enterprises tend to use "exotic" plugins with low installation
> numbers, just because they have specific requirements to their environment
> and scalability. Admins of these instances also tend to disable sending
> usage stats when they discover this option. So I just use personal
> expertise which might be biased due to my Hardware/Embedded background. Ask
> Daniel or Jesse how often they do a facepalm after hearing about my
> use-cases and hacks :)
>
> Speaking seriously, we could definitely think about defining our criteria
> about what we care during such upgrades. Stale plugins and plugins waiting
> for adoption for years should not be a blocker for changes we need as the
> community.
>

I like and support this idea.
I don't think however we should block the Digester work until it's done.
This is something I'd like to help deliver for the next weeks & months so
we can use it for Guava.


>
>
> On Monday, May 31, 2021 at 11:57:12 PM UTC+2 m...@basilcrow.com wrote:
>
>> Dear Oleg,
>>
>> On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev 
>> wrote:
>> > I have commented about the plugins removal in another thread.
>>
>> In particular, you wrote: "From the list, I am particularly concerned
>> about Code Coverage plugins which seemed to be actively used."
>>
>> You expressed concern about Emma, a code coverage plugin with 3,148
>> installations. You did not express concern about BlameSubversion, a
>> plugin not related to code coverage with 825 installations.
>>
>> What, specifically, is the threshold of usage that would cause you to
>> express concern?
>>
>> Thanks,
>> Basil
>>
> --
> 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/7486685b-b93e-4151-b952-8b927bf7f7d0n%40googlegroups.com
> 
> .
>

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

Re: [Digester] Adopt plugins emma & cloverphp

[Baptiste Mathus]

PR https://github.com/jenkins-infra/repository-permissions-updater/pull/1975

Le lun. 31 mai 2021 à 23:10, Baptiste Mathus  a écrit :

> In CC,
> Seiji Sogabe & patrick-brueckner for cloverphp...
> brandt & Manolo Carrasco for emma.
>
> Hi all, I'd like to adopt these two plugins to be able to release them
> with the adaptation for Digester.
>
> For perspective, both plugins' last activity & last release were in 2015:
>
>- https://github.com/jenkinsci/emma-plugin
>- https://github.com/jenkinsci/cloverphp-plugin
>
> I'll create the permissions PR soon.
>
> Thanks
>
> -- Baptiste
>
>

-- 
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/CANWgJS7JOar4unCFLEFmcOrNZEbMqjusdzm_B8Zybxe1R%3D24wg%40mail.gmail.com.

[Digester] Adopt plugins emma & cloverphp

[Baptiste Mathus]

In CC,
Seiji Sogabe & patrick-brueckner for cloverphp...
brandt & Manolo Carrasco for emma.

Hi all, I'd like to adopt these two plugins to be able to release them with
the adaptation for Digester.

For perspective, both plugins' last activity & last release were in 2015:

   - https://github.com/jenkinsci/emma-plugin
   - https://github.com/jenkinsci/cloverphp-plugin

I'll create the permissions PR soon.

Thanks

-- Baptiste

-- 
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/CANWgJS40Z1ooA00SxmD4dzF8uS%2BdtxWEkhD-GtRYkbMrHvH7hg%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Le lun. 31 mai 2021 à 17:41, Oleg Nenashev  a
écrit :

> > Just to make sure I get your point/stance:
> > * you would agree we mark the current PR as ready-for-merge
> > * [provided we enrich the JEP-231 with the following [?]]
> > * to make things better for the future, you recommend we create a
> digester3-api plugin so these plugins can all be updated in one go.
>
> Taking two votes here and many approvals in
> https://github.com/jenkinsci/jenkins/pull/5320, I am not against that. I
> would prefer us to rather follow the new JEP-1 process draft in
> https://github.com/jenkinsci/jep/pull/359 so that we could verify and dry
> run the changes, but I do not want to do modifications for them.
>
> I am not ready to support the PR on my own though,
>

I am not sure exactly sure what you mean by this, but I am certainly not
requesting nor expecting you to support any fallout of this PR.
Our team will obviously step up if something bad arises.


> because we should firstly release the API plugin
>

While, again, I am totally OK to create such a plugin and I'll happily make
it happen this week or so, I disagree with the need to absolutely release
an API plugin before we merge the Core PR. Given the important plugins are
already fixed and released, currently this is more of a maintenance &
technical debt issue.
Functionally, users will see no difference.

What I'm trying to avoid here is stalling this work.
We created this PR on the 1st of March.
The most recent PR to fix even the CMVC plugin (18 installs *worldwide*) is
soon 30 days old.


and do the better effort in reaching out to plugin maintainers and getting
> releases or explicit up-for-adoption where possible.
>

Care to elaborate please?

IIUC you mean sending an email to the last known maintainers for plugins
that are going to be broken when we merge the Core PR.

Reading your email on the users list, if you'd like us to step up and at
least temporarily adopt cloverphp & emma to release them, we can do this.
I'll even start the discussion now.


If other core maintainers do not want to wait, I am ready to accept this
> decision. And I definitely do not want the PR to miss the LTS merge window.
>

Thank you.
Yes, it would certainly be bad for Jenkins future too that it takes us so
long to remove anything :-(.
TBH after this, I fear a bit the Guava upgrade that we want to help on
next...



>
>
>
>
>
>
>
>
>
>
>
> On Sunday, May 30, 2021 at 11:19:25 PM UTC+2 Baptiste Mathus wrote:
>
>> Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  a
>> écrit :
>>
>>> Hi all,
>>>
>>> I have commented about the plugins removal in another thread. I have a
>>> question about creating a detached plugin for commons-digester: *" The
>>> current plan causes plugins which depend on Jenkins to provide Digester to
>>> fail unless they are updated. This could be mitigated by moving this
>>> dependency to a detached plugin. We decided against creating a detached
>>> pluging because there were a small number of affected plugins and only a
>>> few of them have significant install base. The creating and maintaining of
>>> a detached plugin would still be a significant amount of work and would
>>> cause the security vulnerabilities we are trying to address to remain open"*
>>>
>>> I agree with the reasoning and the decision. At the same time time it
>>> does not explain why the commons-digester3 library is being injected as a
>>> direct dependency in pull requests, e.g.
>>> https://github.com/jenkinsci/vs-code-metrics-plugin/pull/5/ . Would it
>>> make sense to create a new API plugin instead? Otherwise we risk running
>>> into compatibility concerns at some point. Creating an API plugin is not
>>> discussed in the JEP at all.
>>>
>>
>> Right. We could create a digester3-api plugin.
>>
>> Indeed, to follow your point: currently, plugins were theoritically (in
>> practice never, given digester2 is lng deprecated) getting this
>> centralized at Jenkins Core level.
>> It was kinda like these plugins were using an api-plugin.
>>
>> Now for adjusted plugins, each one would have to upgrade separately
>> when/if a new release is made for digester3.
>>
>> Just to make sure I get your point/stance:
>> * you would agree we mark the current PR as ready-for-merge
>> * [provided we enrich the JEP-231 with the following [?]]
>> * to make things better for the future, you recommend we create a
>> digester3-api plugin so these plugins can all be updated in one go.
>>
>> I think I like this idea. This whole Digester2 work is about cleaning up
>> some burden of Jenkins, a

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Le dim. 30 mai 2021 à 20:55, Oleg Nenashev  a
écrit :

> Hi all,
>
> I have commented about the plugins removal in another thread. I have a
> question about creating a detached plugin for commons-digester: *" The
> current plan causes plugins which depend on Jenkins to provide Digester to
> fail unless they are updated. This could be mitigated by moving this
> dependency to a detached plugin. We decided against creating a detached
> pluging because there were a small number of affected plugins and only a
> few of them have significant install base. The creating and maintaining of
> a detached plugin would still be a significant amount of work and would
> cause the security vulnerabilities we are trying to address to remain open"*
>
> I agree with the reasoning and the decision. At the same time time it does
> not explain why the commons-digester3 library is being injected as a direct
> dependency in pull requests, e.g.
> https://github.com/jenkinsci/vs-code-metrics-plugin/pull/5/ . Would it
> make sense to create a new API plugin instead? Otherwise we risk running
> into compatibility concerns at some point. Creating an API plugin is not
> discussed in the JEP at all.
>

Right. We could create a digester3-api plugin.

Indeed, to follow your point: currently, plugins were theoritically (in
practice never, given digester2 is lng deprecated) getting this
centralized at Jenkins Core level.
It was kinda like these plugins were using an api-plugin.

Now for adjusted plugins, each one would have to upgrade separately when/if
a new release is made for digester3.

Just to make sure I get your point/stance:
* you would agree we mark the current PR as ready-for-merge
* [provided we enrich the JEP-231 with the following [?]]
* to make things better for the future, you recommend we create a
digester3-api plugin so these plugins can all be updated in one go.

I think I like this idea. This whole Digester2 work is about cleaning up
some burden of Jenkins, and such an API plugin would avoid having to
manually update dozens of plugins if a vulnerability fix was to be released
on the digester3 line.

We can definitely and happily commit to create such an API plugin and adapt
active plugins if that is the last blocker us to move forward and merge
this PR in the Core :-).

Are we missing anything else to allow this merge?

What do you think Oleg? What do you all think?


> Best regards,
> Oleg Nenashev
>
> P.S: Sorry for being a bit late to comment
>
> On Saturday, May 29, 2021 at 2:41:26 AM UTC+2 boa...@gmail.com wrote:
>
>> +1 thanks for doing your due diligence!
>>
>> On Fri, May 28, 2021 at 19:14 Basil Crow  wrote:
>>
>>> +1 from me
>>
>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrQBdo645Zs5cboXStgo_7zJEEsnQ3iCxQ6qC4iw4M%3D4g%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/4b2291aa-2a87-4d62-992b-c944b1c19aa4n%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/CANWgJS4L1utmL3r9zG0_VSmD5SqM-QRv9GdyYLXaVcjTi3rjZg%40mail.gmail.com.

Re: Proposal: Open Governance - Tracking key action items/requests in GitHub Issues

[Baptiste Mathus]

I think that's a great idea. +1

Typically I suppose we'll create an issue for the LTS baseline selection,
etc. We'll also then get for free linking between PRs and issues (like the
release lead checklist, the backporting PR etc.)

I'm slightly concerned it may reduce our discussions here but there's no
silver bullet.

-- Baptiste

Le lun. 17 mai 2021 à 23:59, Oleg Nenashev  a
écrit :

> Hi all,
>
> I would like to follow-up on a Jenkins governance help offer from Rick in this
> thread .
>
> Currently we do the most of the planning and discussions via mailing lists
> and governance meetings. For common community members, it might be
> difficult to see what are the initiatives/projects being handled by the
> board at the moment. It is also hard for potential contributors to see the
> governance backlog and to contribute to the open items in our TODO list.
>
> What if we create a new public github repo like jenkinsci/governance and
> put key issues/projects there, e.g. (Adoption of EasyCLA, CDF Project
> representatives Elections, Contributor summit, etc.). It should not be a
> replacement for the mailing lists OR a micromanagement tool, but we can use
> it to provide a way to highlight key problems we are about working on. The
> new repo can be also used as a public RFE tracker and maybe even a Q
> forum for the governance matters though, again, it should not replace the
> mailing discussions.
>
> Such approach would partially overlap with the Jenkins public roadmap, but
> only for big initiatives which need to be represented there.
>
> What do you think?
>
> Best regards,
> Oleg Nenashev
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/92e0af37-e7eb-49c8-8c10-599daf071928n%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/CANWgJS684sxzEPanEcE%2Bb_W84L3wzNZQAgbzu6fuCaKcPdWBBw%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Le mer. 5 mai 2021 à 19:08, Jesse Glick  a écrit :

> On Tue, May 4, 2021 at 10:58 PM Oleg Nenashev 
> wrote:
>
>> What about a quick JEP?
>>
>
> The rule of thumb is that if you are not sure if a JEP might be
> needed…file a JEP. It is how we document any decision that might be
> controversial or require explanation or context. Certainly any
> deliberate compatibility break falls into this category. If your arguments
> for why we should do something are coherent, it should not take long to
> write up a few paragraphs in AsciiDoc and file it.
>

Agreed. We'll do one

-- 
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/CANWgJS4gSYUdpZAo%3Dxgp8U8nhj9YzEoMJM85A3b4LAWqaMU%3Dqg%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Exactly what Liam said.

I did call out this very page about "compatibility matters" on my first
mail in this thread.

I think we *are* being extremely careful. We even filed PRs on plugins that
the Jenkins Project does not serve anymore and/or plugins abandoned since
close to 10 years.

Le mer. 5 mai 2021 à 17:28, Liam Newman  a écrit :

> Daniel,
>
> From that link:
>
>> This is not to say we don’t ever remove anything, but we do it very
>> carefully.
>>
>
> We are being careful.  I think creating a JEP, even a mostly retrospective
> one, is worth doing.  If nothing else we should do so because of concerns
> like those voiced by Daniel. I will take that task on myself if needed.
>
>   -L.
>
>
> On Wed, May 5, 2021 at 5:14 AM Daniel Beck  wrote:
>
>>
>>
>> > On 5. May 2021, at 09:41, Manuel Ramón León Jiménez <
>> manuelramonleonjime...@gmail.com> wrote:
>> >
>> > I'm against a JEP for Digester removal. It doesn't need it IMO. I'm in
>> for anything to avoid us dealing with the same problems in the future. We
>> need to modernize Jenkins in many aspects and those old / unmaintained
>> plugins are an obstacle and a waste of effort.
>>
>> Time to delete
>> https://www.jenkins.io/project/governance/#compatibility-matters then,
>> because looking at this thread, compatibility clearly doesn't matter
>> anymore?
>>
>> --
>> 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/B214EACA-57A8-4EB4-9FFA-C59B2F0D9D89%40beckweb.net
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAA0qCNwD%3DMMh5i%2BjeEte6CxRqQ%3DcCVEZqmNMxtPcgC8JUJ_0vA%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/CANWgJS6rpBamE_3%3DVGbFjKepLW%3DrdWbkCazF6Jhm5KGo1f2f5g%40mail.gmail.com.

Re: Jenkins Governance Meeting on May 05, 2021

[Baptiste Mathus]

Yes, socializing the idea at this point I would say. And probably getting
some potential feedback on the proposed action plan.

As much as I would obviously love to move forward sooner than later, I
think asking for a decision already would be a bit too early and
disingenuous from me. 


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

> Hu Baptiste. No objections from me w.r.t. adding it to the agenda. Do you
> expect to get a deciaion there? Or is it just a way to socialiye the
> proposal? Both options LGTM
>
> On Tue, May 4, 2021, 23:05 Baptiste Mathus  wrote:
>
>> Hi Oleg, hi everyone,
>>
>> I've just sent an email update in the other thread about
>> commons-digester:2.1.
>> If you think this would be worth raising this too during the governance
>> meeting, I can probably try and join this time (given 20:00 UTC+1 can work
>> for me, thanks Summer time :)).
>>
>> -- Baptiste
>>
>> Le mar. 4 mai 2021 à 19:16, Oleg Nenashev  a
>> écrit :
>>
>>> Dear all,
>>>
>>> Tomorrow we will have the regular Jenkins Governance meeting. The
>>> meeting will start at 7PM UTC, everyone is welcome to participate! Calendar
>>> link: here
>>> <https://calendar.google.com/event?action=TEMPLATE=dThldWFobzZyM2NwcTllM3RxaXRhZzhrczJfMjAyMTA1MDVUMTkwMDAwWiA0c3MxMmYwbXFyM3RicDF0MmZlMzY5c2xmNEBn=4ss12f0mqr3tbp1t2fe369slf4%40group.calendar.google.com>
>>>
>>> Current topics (full agenda and links
>>> <https://docs.google.com/document/d/11Nr8QpqYgBiZjORplL_3Zkwys2qK1vEvK-NYyYa4rzg/edit#heading=h.1gtco63t6ztr>
>>> ):
>>>
>>>- News: 2.277.4 Release, SheCodeAfrica summary, DevOps World
>>>- Confirming the CDF TOC project representative nomination for
>>>Jenkins
>>>- Terminology updates - finalizing the terms
>>>- Update on the Hosting team
>>>- Jenkins SDLC security - confirming the pilot project with LFX
>>>Security and Snyk
>>>- Roadmap Updates Review
>>>- JEP Process updates (and BDFL?)
>>>- TBD: GitHub Issues for open governance projects/backlog
>>>- TBD: Plugin End-of-Life Policy
>>>
>>> If you want to add a topic, please suggest a topic in the Google Doc.
>>> Note that we also have the Roadmap Review topic in the list. Everyone is
>>> encouraged to submit their roadmap updates to the jenkins.io repo so
>>> that we review them tomorrow:
>>> https://github.com/jenkins-infra/jenkins.io/labels/roadmap .
>>>
>>> #MayThe4BeWithYou,
>>> Oleg Nenashev
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/3eb70f0b-389a-46c5-ba53-63d5e36357edn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/3eb70f0b-389a-46c5-ba53-63d5e36357edn%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/YzRC7tvi8tA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6ZSk%2B-Q6rJOHgee__QqQi2Rree3QGoNfoTtyZcz%2BQXZA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6ZSk%2B-Q6rJOHgee__QqQi2Rree3QGoNfoTtyZcz%2BQXZA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAPfivLDRcH41CNniO_UCACfDXMbLf%3Dtw58FpXwCbWwf6GujFzw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDRcH41CNniO_UCACfDXMbLf%3Dtw58FpXwCbWwf6GujFzw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

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

Re: Jenkins Governance Meeting on May 05, 2021

[Baptiste Mathus]

Hi Oleg, hi everyone,

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

-- Baptiste

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

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

-- 
You received this message because you are subscribed to 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/CANWgJS6ZSk%2B-Q6rJOHgee__QqQi2Rree3QGoNfoTtyZcz%2BQXZA%40mail.gmail.com.

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Hi all, so our team landed all 23 PRs needed to adapt the identified
impacted plugins in the ecosystem.
The thing is: in those PRs, many plugins are just abandoned, some since up
to 9 years.

The detailed status table is available on the PR itself:
https://github.com/jenkinsci/jenkins/pull/5320
I have just done another round of status assessment on the whole list.

In summary the status is the following:

   - subversion, maven-info and clover: Done. They got a release already.
   (thanks Tim, Marek & Olivier!)
   - cvs fix is merged, waiting for a release. (this is really the only
   must-have to me, cvs still being reported as installed 40k times...)

These 4 above are the most installed plugins impacted by the removal of
commons-digester.
The least popular of these 4 is clover with 3521 installs.

In short, here are the plugins that I do not think we will get a merge,
even less a release for, because of lack of maintainership:

   - emma 3216
   - cloverphp 2801
   - vs-code-metrics 1435
   - BlameSubversion 878
   - javatest-report 440
   - clearcase-ucm 266
   - vss 168
   - synergy 96
   - config-rotator 62
   - harvest 49
   - cmvc 18


So the big question is: what do we do?

I personally think we should NOT make these PRs land if no maintainer steps
up.
In other words, once we merge and release the Core PR, these plugins will
likely just fail loading on newer Jenkins releases.

I'm proposing the following action plan to move forward:

   - This week: blog entry on Jenkins.io summarizing this and heads-up to
   users for these plugins
   - Some time next week: merge
   https://github.com/jenkinsci/jenkins/pull/5320
  - this way we still give some more time to plugins to be released
  (like cvs).
  - 2021-05-17: the first weekly without commons-digester:2.1 is
  released.
   - anything else?

(I'm also thinking we might want to consider using an AdminMonitor, like
the PluginDeprecationMonitor?
<https://github.com/jenkinsci/jenkins/blob/6384f1965f290494332cc4853ddbadadd728e810/core/src/main/java/hudson/PluginManager.java#L2389>,
not sure anymore what we'd do nowadays for such case?)

WDYT?


Le lun. 3 mai 2021 à 10:33, Oleg Nenashev  a écrit :

> Hi Baptiste,
>
> Thanks a lot for this work! Commons Digester is definitely a legacy that
> we should rather remove from Jenkins. It should be perfectly fine as long
> as we provide an upgrade path in plugins, timely deprecate and announce the
> removal. We're doing pretty much the same process for Ruby and Python
> plugin runtimes, and the process can be partially inherited from that or,
> if you prefer a longer rollout, from JEP-200.
>
> If we have many such removals, slated for a single release, maybe we
> should consider doing Jenkins 3. I have a proposal in works towards the
> contributor summit in June, but I am not ready to share it yet.
>
> Best regards,
> Oleg Nenashev
>
> P.S: +100 for referencing Shifting Gears!
>
>
> On Sunday, May 2, 2021 at 10:52:26 PM UTC+2 Baptiste Mathus wrote:
>
>> Hi all,
>>
>> I was considering just posting a link in the plugins EOL thread, but
>> thought I'd fork to keep the other thread focused. (and not end up stealing
>> it).
>>
>> We are currently working on *removing* commons-digester:2.1
>> <https://search.maven.org/artifact/commons-digester/commons-digester/2.1/jar>
>> from Jenkins Core.
>>
>> *https://github.com/jenkinsci/jenkins/pull/5320
>> <https://github.com/jenkinsci/jenkins/pull/5320>*
>>
>> After considering an upgrade, we chose the removal path. In particular
>> because the very reason why it is outdated (2010...) and hard to update is
>> that it leaked since many years in the whole Jenkins ecosystem. So we are
>> doing what is deemed right by many, rather than just upgrading so we're in
>> the same situation in 5+ years from now.
>> As Jesse put it
>> <https://github.com/jenkinsci/jenkins/pull/5320#issuecomment-790114286>:
>>
>> *I would rather suggest deprecating Digester2 and maybe detaching it to a
>> split plugin, unless we can kill all plugin references.*
>>
>>
>> After analyzing the impact, we are now pursuing the "unless" part :-).
>> We're fixing the ecosystem instead. 20 plugin PRs, counting.
>>
>> So this email has a few purposes:
>>
>>1. Raise awareness on these 20+ PRs we opened to fix the ecosystem.
>>If you are a Jenkins plugin maintainer, please look at the list in the
>>table in the description of the Core PR above
>><https://github.com/jenkinsci/jenkins/pull/5320>.
>>2. Add an interesting data point to the plugin EOL policy discussion:
>>you'll see that in these PRs, a lot are on *very* old plugins, which many
>>look unm

[Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

[Baptiste Mathus]

Hi all,

I was considering just posting a link in the plugins EOL thread, but
thought I'd fork to keep the other thread focused. (and not end up stealing
it).

We are currently working on *removing* commons-digester:2.1

from Jenkins Core.

*https://github.com/jenkinsci/jenkins/pull/5320
*

After considering an upgrade, we chose the removal path. In particular
because the very reason why it is outdated (2010...) and hard to update is
that it leaked since many years in the whole Jenkins ecosystem. So we are
doing what is deemed right by many, rather than just upgrading so we're in
the same situation in 5+ years from now.
As Jesse put it
:

*I would rather suggest deprecating Digester2 and maybe detaching it to a
split plugin, unless we can kill all plugin references.*


After analyzing the impact, we are now pursuing the "unless" part :-).
We're fixing the ecosystem instead. 20 plugin PRs, counting.

So this email has a few purposes:

   1. Raise awareness on these 20+ PRs we opened to fix the ecosystem. If
   you are a Jenkins plugin maintainer, please look at the list in the table
   in the description of the Core PR above
   .
   2. Add an interesting data point to the plugin EOL policy discussion:
   you'll see that in these PRs, a lot are on *very* old plugins, which many
   look unmaintained. If the policy was in place already, this may have
   simplified our work subtantially. And I do think this is vital for us that
   we can spend our scarce time rather on making Jenkins shine, than on making
   sure plugins released last 5 to 9 years ago, with less than 200 installs
   worldwide, still work...
   3. *Custom plugins: if you have developed a custom in-house plugin in
   your company, please make sure to NOT use commons-digester anymore from
   Jenkins Core.*


Given Guava update/removal is another (_much_ bigger) subject in the radar,
I thought raising this would be a good thing for a global awareness.
Again, I think being able to tackle such cleanup tasks is vital to our
continued success.
Being stuck to use some 10+ years old dependencies in our beloved tool
cannot be a good thing.
While we have always valued compatibility deeply
, we also
accepted that potentially breaking some things
 is critical for us
to be able to focus more of our time on the right things.

-- Baptiste

-- 
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/CANWgJS5YdwNL_CExjed%2B4R-jcDyai-BPPRhR-PkNvZRm%3Dk4u%3Dw%40mail.gmail.com.

Re: Plugin end-of-life (EOL) policy

[Baptiste Mathus]

Oh, and: given the nature of our project, I think defining a clear way to
un-EOL a plugin would likely be needed too.
It's probable that we'll EOL some plugins, and after say 1 or 2 years some
folks will want to revive some of the plugins that got EOLed.

It may seem backward, but I think it's a healthy thing. The bottom line and
expectation is that anyway we'll probably EOL dozens of plugins quickly and
only a handful will be requested to be unEOLed (meaning, after a
transitional pre-EOL warning period and nobody has complained during this
one).

-- Baptiste

Le mar. 27 avr. 2021 à 09:24, Baptiste Mathus  a écrit :

> I agree this is an initiative definitely worth pursuing. We all know this
> is a pain.
>
> On criteria for defining whether a plugin should be EOLed, I think the
> best idea I have seen so far was Stephen's:
>
> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/jenkinsci-dev/Ih0RviQ0G90/NmoVJQ1j6NAJ
>
> Basically automated regular PRs allowing for a global detection of plugins
> without an active maintainer.
> That maintainer's existence/reactivity + some criteria TBD (like last
> release date, the number of open jira issues, etc.) would help us decide
> whether or not start an EOL process.
>
> Anyway, however we define these criteria, which discussion I think we can
> handle separately, defining an EOL process I think has become vital indeed
> for the Jenkins Project to keep thriving.
>
>
> Le mar. 27 avr. 2021 à 04:00, Basil Crow  a écrit :
>
>> Abandoned plugins cause friction for both Jenkins users and contributors
>> alike.
>>
>> They cause friction for users because they are unlikely to be simpatico
>> with newer features like Pipeline. In the worst case, they are downright
>> incompatible with newer features like Configuration Form Modernization
>> and cause breakage that is difficult for users to resolve.
>>
>> They cause friction for contributors by making it difficult to perform
>> project-wide changes, such as Configuration Form Modernization or
>> dependency updates.
>>
>> True, distributing as many plugins as possible for as long as possible
>> maximizes the value the project provides and maintains the project's
>> strong reputation for flexibility. Yet, treating abandoned plugins as
>> first-class citizens indefinitely carries a non-trivial cost, and that
>> cost only increases the longer a plugin remains abandoned.
>>
>> The project is over 15 years old, and some plugins have been abandoned
>> for the better part of a decade. Many of these plugins will likely
>> remain abandoned for the next decade. At what point does the cost of
>> carrying these plugins outweigh the benefit?
>>
>> I do not know the answer, but I do know that the answer is not "never".
>> Contributor bandwidth is a finite resource. However, there remain
>> hundreds of plugins that have been abandoned for the better part of a
>> decade yet are seemingly presented as first-class citizens without so
>> much as a deprecation notice. This does not seem sustainable.
>>
>> I would like to propose that we define a process for plugin end-of-life:
>> initially marking such plugins as deprecated, then eventually removing
>> such plugins from distribution.
>>
>> How would we decide when to deprecate a plugin or remove it from
>> distribution? We could use metrics such as the number of days since the
>> last release and the number of installations. For example, we could
>> declare that any plugin that has not been released in five years would
>> be automatically deprecated and that any plugin that has remained
>> deprecated for more than five years would be removed from distribution.
>> We could put escape hatches in place to exempt sufficiently popular
>> plugins from this policy.
>>
>> I do not have a strong preference as to how long the support window
>> should be. But I do have a strong preference that it be finite:
>> supporting an unbounded number of plugins as first-class citizens for an
>> unbounded amount of time does not seem sustainable.
>>
>> I can already hear Oleg calling for a blog post to be written announcing
>> such a policy months in advance of its implementation, were such a
>> policy to be agreed upon. That would be fine by me as well. Again, the
>> point is not to be overly aggressive or to surprise users, but rather to
>> put reasonable limits in place that support the project's long-term
>> goals given the finite resources that are available.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers&quo

Re: Plugin end-of-life (EOL) policy

[Baptiste Mathus]

I agree this is an initiative definitely worth pursuing. We all know this
is a pain.

On criteria for defining whether a plugin should be EOLed, I think the best
idea I have seen so far was Stephen's:
https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/jenkinsci-dev/Ih0RviQ0G90/NmoVJQ1j6NAJ

Basically automated regular PRs allowing for a global detection of plugins
without an active maintainer.
That maintainer's existence/reactivity + some criteria TBD (like last
release date, the number of open jira issues, etc.) would help us decide
whether or not start an EOL process.

Anyway, however we define these criteria, which discussion I think we can
handle separately, defining an EOL process I think has become vital indeed
for the Jenkins Project to keep thriving.


Le mar. 27 avr. 2021 à 04:00, Basil Crow  a écrit :

> Abandoned plugins cause friction for both Jenkins users and contributors
> alike.
>
> They cause friction for users because they are unlikely to be simpatico
> with newer features like Pipeline. In the worst case, they are downright
> incompatible with newer features like Configuration Form Modernization
> and cause breakage that is difficult for users to resolve.
>
> They cause friction for contributors by making it difficult to perform
> project-wide changes, such as Configuration Form Modernization or
> dependency updates.
>
> True, distributing as many plugins as possible for as long as possible
> maximizes the value the project provides and maintains the project's
> strong reputation for flexibility. Yet, treating abandoned plugins as
> first-class citizens indefinitely carries a non-trivial cost, and that
> cost only increases the longer a plugin remains abandoned.
>
> The project is over 15 years old, and some plugins have been abandoned
> for the better part of a decade. Many of these plugins will likely
> remain abandoned for the next decade. At what point does the cost of
> carrying these plugins outweigh the benefit?
>
> I do not know the answer, but I do know that the answer is not "never".
> Contributor bandwidth is a finite resource. However, there remain
> hundreds of plugins that have been abandoned for the better part of a
> decade yet are seemingly presented as first-class citizens without so
> much as a deprecation notice. This does not seem sustainable.
>
> I would like to propose that we define a process for plugin end-of-life:
> initially marking such plugins as deprecated, then eventually removing
> such plugins from distribution.
>
> How would we decide when to deprecate a plugin or remove it from
> distribution? We could use metrics such as the number of days since the
> last release and the number of installations. For example, we could
> declare that any plugin that has not been released in five years would
> be automatically deprecated and that any plugin that has remained
> deprecated for more than five years would be removed from distribution.
> We could put escape hatches in place to exempt sufficiently popular
> plugins from this policy.
>
> I do not have a strong preference as to how long the support window
> should be. But I do have a strong preference that it be finite:
> supporting an unbounded number of plugins as first-class citizens for an
> unbounded amount of time does not seem sustainable.
>
> I can already hear Oleg calling for a blog post to be written announcing
> such a policy months in advance of its implementation, were such a
> policy to be agreed upon. That would be fine by me as well. Again, the
> point is not to be overly aggressive or to surprise users, but rather to
> put reasonable limits in place that support the project's long-term
> goals given the finite resources that are available.
>
> --
> 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/CAFwNDjoNMRbkDdkcjYMZSauCfE%2BRQ6pkv_jGG5W2RTqaDiJM2w%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/CANWgJS4Y7tdk345Du3ooV87ayxEcgy6yQX2EctyAJ-zv1hwzEw%40mail.gmail.com.

Re: Jenkins LTS baseline selection

[Baptiste Mathus]

Thanks for raising this Tim.
As I've written on IRC, as long as we choose 2.288+, I'm happy :).

Can you please confirm the expected timeline, so we can better assess
things?
Re-reading https://www.jenkins.io/download/lts/ we're looking at a .1 6
weeks from now, i.e. some time around 2021-06-02 right ?

If so, I agree even choosing the upcoming 2.289 could be acceptable with
such a testing period.

-- Baptiste




Given the expected usua



Le mar. 20 avr. 2021 à 08:53, Tim Jacomb  a écrit :

> Hello everyone,
>
> Please voice your opinion on which version should be our next core
> baseline.
>
> For me it looks like either 2.288 or 2.289 are the options
>
> 2.289 (being released today) includes a change for an upcoming firefox
> version so it would be good to get it in, but it hasn't had any weekly
> soaking time so we could use 2.288 and then backport it in if we don't find
> any issues?
>
> What do you think?
>
> Thanks
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidOjTQoUe7Y4q7m-9hp_UN6JX9t1xNyQTdhwNk3M1LqVg%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/CANWgJS7o6mGZttw4uo2r2RNqHnf7haaSFVmPcUEsphV7ynwkeA%40mail.gmail.com.

Re: Deprecating ruby-runtime

[Baptiste Mathus]

+1 for deprecating this. The Jenkins community should invest its time more
into the future than these components that are lacking any kind of
maintainership.

Cheers

Le jeu. 15 avr. 2021 à 04:55, Owen Mehegan  a écrit :

> gitlab-plugin doesn't depend on it, but gitlab-hook plugin does. It has
> been unmaintained for 5 years and functionality is replaced by
> gitlab-plugin and gitlab-branch-source.
>
> On Thu, Apr 15, 2021, 12:39 PM Jim Klimov  wrote:
>
>> On April 14, 2021 6:45:30 PM UTC, Oleg Nenashev 
>> wrote:
>> >I am +1 for depreciation. I would recommend to make an announcement
>> >blog
>> >about that with e.g. 1-month advance notice, but there is no reason to
>> >keep
>> >these plugins around. Ruby plugin stack is not maintainable without a
>> >full-time contributor, we should pick our battles
>> >
>> >On Wed, Apr 14, 2021, 20:36 Mark Waite 
>> >wrote:
>> >
>> >>
>> >>
>> >> On Wed, Apr 14, 2021 at 12:20 PM Daniel Beck  wrote:
>> >>
>> >>>
>> >>> Since the last time we discussed this (and I created the JEP), we
>> >added
>> >>> deprecation warning support to Jenkins 2.246 and newer, which is
>> >basically
>> >>> designed for such a case. This makes JEP-7 much cleaner to
>> >implement,
>> >>> because we now have good ways to inform users about it.
>> >>>
>> >>> I'd start with a deprecation warning for ruby-runtime and all
>> >dependent
>> >>> plugins pointing to the JEP or this thread (or, if you want to write
>> >it up,
>> >>> a blog post), and if folks don't complain offer to take over
>> >>> ruby-runtime maintainership in large enough numbers, we can suspend
>> >a few
>> >>> weeks later, followed by core cleanup. WDYT?
>> >>>
>> >>>
>> >> +1 from me.
>> >>
>> >>
>> >> --
>> >> You received this message because you are subscribed to a topic in
>> >the
>> >> Google Groups "Jenkins Developers" group.
>> >> To unsubscribe from this topic, visit
>> >>
>> >https://groups.google.com/d/topic/jenkinsci-dev/Ve0fqAud3Mk/unsubscribe.
>> >> To unsubscribe from this group and all its topics, send an email to
>> >> jenkinsci-dev+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFpo1yfG81wQYMUYp9vq3wFP%2BE40zA5cyAuZLYAQF83JQ%40mail.gmail.com
>> >>
>> ><
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFpo1yfG81wQYMUYp9vq3wFP%2BE40zA5cyAuZLYAQF83JQ%40mail.gmail.com?utm_medium=email_source=footer
>> >
>> >> .
>> >>
>>
>> I believe there were plugins depending on it, that got me to have to pick
>> java8 explicitly on one system. I think gitlab-plugin might be it.
>>
>> Jim
>>
>> --
>> Typos courtesy of K-9 Mail on my Android
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/Ve0fqAud3Mk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/DCF391B5-3BB1-415C-BD17-10E0D2859FE6%40cos.ru
>> .
>>
> --
> 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/CAHtcACEF8CtS5%2Bmd2WbipJSt0S9EHhp_ZJ96ZQ30KgTqXm4%3DEg%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/CANWgJS7dJQEY2KZna96%2B%2BqwjpgjzqMAues%3DBDDM22FTmxsi4%3DQ%40mail.gmail.com.

Re: Welcome Ewelina Wilkosz - new Jenkins Governance Board Member

[Baptiste Mathus]

Congrats Ewelina! :)

Le lun. 15 mars 2021 à 12:56, Oleg Nenashev  a
écrit :

> Dear all,
>
> We are happy to announce that we have finished the interim board member
> selection procedure. The Mar 10 Governance meeting has confirmed Ewelina
> Wilkosz as a new Jenkins Governance Board member who will replace Marky
> Jackson in this role. The term will last until the Jenkins elections in
> late 2022. Ewelina's statement from the 2020 elections is available here
> 
> .
>
> About Ewelina : *Jenkins
> Contributor since 2017, when she got involved in Jenkins Configuration as
> Code Plugin development. Voted Most Valuable Contributor in 2018. **She
> has 14 years of experience in IT, working as a CI/CD consultant since the
> beginning of 2017. In that role she’s trying to solve* *numerous issues
> Jenkins users are facing daily - as developers, administrators, maintainers*
> *.*
>
> Welcome aboard Ewelina!
>
> Best regards,
> Oleg Nenashev
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLC3jALq-E%3DC%3Dt_in_H2_C%3DoaHUdqMo8PLYNOEMFf8Fhqg%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/CANWgJS73MrDbWn%2B5hjdv6uPTp4onpEqfgSf7y3gdm2L3Uff1vA%40mail.gmail.com.

Re: Speed up Artifact Copy between slave and master

[Baptiste Mathus]

Le mer. 3 mars 2021 à 06:44, Tim Black  a écrit :

> Think I found it: NameMangler.apply()
> .
> Would it be possible/advised to import the NameMangler class in my Shared
> Library vars/scpArtifacts.groovy (assuming my Jenkins instance has
> branch-api plugin installed, which it does.) Something like this:
>
> ```
> import jenkins.branch.NameMangler
> def mangled_branch_name = NameMangler.apply(branch_name)
> ```
>
> I'll try this out in the morning, just curious if anyone can confirm
> whether this looks feasible or I'm way off track. Thanks.
>

Using core java classes from Jenkins pipeline shared library is generally
strongly discouraged.
This could break from one day to another without notice.
What you're working on looks like it should rather be done in a full-blown
Jenkins plugin.
(If not, this discussion should be on the users mailing list)


>
> On Tuesday, March 2, 2021 at 8:03:57 PM UTC-8 Jesse Glick wrote:
>
>> The principal class to look at is `MultiBranchProject`.
>>
> --
> 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/40b68498-b2ba-4e02-9c23-1eb76c04709an%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/CANWgJS61vkmc_O9mgS1YYOy_CF_Vh92LvkQ0%3D0rQW7Vi5_DKUw%40mail.gmail.com.

Re: Optional automated source code formatting - prep for JEP

[Baptiste Mathus]

Thinking about this more, I agree the right phase should be on
both process-resources and process-test-resources respectively (though a
bit surprising for users indeed).

On the way it should operate: I was going to propose a CI-only flag to fail
there when a format is not good, but to avoid the CI surprise, I'm thinking
the standard build should:
* Detect a formatting change need, do it, and non-zero exit
Or
* Detect no formatting need and do nothing

This way the behavior is the same locally and in Jenkins, and it should not
be too disruptive as it's not very late in the Maven lifecycle.

I think non-zero exiting is useful locally, so you don't end up git add &
commit, mvn test, git push but then get a CI failure because you had a
local formatting change you didn't add before pushing.

Le mar. 24 juil. 2018 à 22:44, Liam Newman  a écrit :

> The auto format should occur before the compile stage, probably during
> process-sources


>
>
>
> On Tue, Jul 24, 2018, 6:00 AM Baptiste Mathus  wrote:
>
>> Great idea and initiative IMO, thanks a bunch for driving this Mark.
>>
>> Over the years, I've become more and more strongly opinionated that *a*
>> common format is defined, and easily applied, and less and less about the
>> precise format.
>> IOW, I generally do have opinions about where curly brackets and others
>> should go, but I'll happily put them aside if this helps us define
>> *something*.
>>
>> @Mark you can use https://github.com/jenkinsci/buildtriggerbadge-plugin
>> or https://github.com/jenkinsci/essentials-plugin and few others to test
>> drive this.
>> https://github.com/jenkinsci/radiatorview-plugin might also be
>> interesting as it has a bit more code, and has been existing for quite long
>> I think.
>>
>> -- Baptiste
>>
>>
>>
>> Le mar. 24 juil. 2018 à 03:36, Mark Waite  a
>> écrit :
>>
>>> I'd like to submit a Jenkins Enhancement Proposal for optional automated
>>> source code formatting available from the plugin pom so that plugins which
>>> build with maven could choose to "opt-in" to automated source code
>>> formatting.
>>>
>>> Key attributes of the idea:
>>>
>>>- *Optional* - plugins only get source code formatting if they
>>>enable it
>>>- *Automatic* - when source code formatting is enabled, it happens
>>>automatically as part of the maven compile phase
>>>- *Common* - when source code formatting is enabled, the source code
>>>formatting settings are not intended to be altered by the plugin
>>>
>>> I've implemented a sample in the platformlabeler plugin
>>> <https://github.com/jenkinsci/platformlabeler-plugin/blob/fcae9d81f557c4fdcb1b991487e28113f718a81d/pom.xml#L76>
>>> using the "FMT Maven plugin
>>> <https://mvnrepository.com/artifact/com.coveo/fmt-maven-plugin>" which
>>> uses google-java-format <https://github.com/google/google-java-format>
>>> to format Java source code to Google Java Style
>>> <https://google.github.io/styleguide/javaguide.html>.
>>>
>>> Key questions that need discussion (especially considering my feeble
>>> skills with maven):
>>>
>>>- Is optional automated source formatting of interest to a few
>>>plugin developers that would be willing to test drive it?  If so, who are
>>>the plugin developers that are willing to test drive it, and which 
>>> plugins
>>>will be involved in the test drive?  I'll use platformlabeler as one of 
>>> the
>>>test drive plugins.  Others will be needed
>>>- How would a prototype of optional automated source formatting be
>>>evaluated?  By releasing a beta version of the plugin parent pom
>>>
>>> <https://github.com/jenkinsci/plugin-pom/blob/8224b204a5646d4292da7b3e38876ca6fbde9c33/pom.xml#L580>?
>>>Some other means?
>>>- Would automated formatting be integrated into the plugin parent
>>>pom using techniques similar to the findbugs integration
>>>
>>> <https://github.com/jenkinsci/plugin-pom/blob/8224b204a5646d4292da7b3e38876ca6fbde9c33/pom.xml#L580>
>>>into the plugin parent pom, or is there a better way?
>>>- Is "google java format" an acceptable code format for those plugin
>>>authors that are willing to adopt automated code formatting?
>>>- Are there other issues that need to be addressed before a Jenkins
>>>Enhancement Proposal is submitted for optional automated source code
>>>   

Archive https://github.com/jenkinsci/stride-notification-plugin ?

[Baptiste Mathus]

Hey all,
Got a heads-up from Tim on an old PR of mine at
https://github.com/jenkinsci/stride-notification-plugin/pull/1

I think we should archive this plugin given its state:
* Atlassian Stride, which this plugin connects to, got EoLed in Feb 2019
* This plugin never had a release (no git tag at least)
* the plugin is basically one class 
* the last commit is 3 years old

If nobody opposes, I'll proceed sometime next week after Wed the 13th of
January

Thanks

-- Baptiste

-- 
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/CANWgJS4isuCKm2yH9-w6Ni6kdDS92a4%2BGgEgOV324At9RAaF7w%40mail.gmail.com.

Re: [DISCUSS] Dependabot for Jenkins core (was:Re: Proposal: Automating dependency management for repositories inside the jenkinsci org)

[Baptiste Mathus]

OK, I've just filed https://github.com/jenkinsci/jenkins/pull/5108 as Jesse
and Tim are suggesting we go the "deny" path.

I think indeed the idea to deny/ignore the dependency that we know they
shouldn't be automated is probably good as we may see some interesting
things.

@Oleg Nenashev  if you feel strongly we should
really add things more progressively, just tell me. I'm fine and I'll
adjust the PR or create a new one with a proposal of first deps.

Thanks all!

Le ven. 11 déc. 2020 à 15:39, Jesse Glick  a écrit :

> I would suggest using a deny list. You will get an initial spray of
> PRs, mostly to `bom/pom.xml`. Some we will reject as unsafe (likely
> breaking change for plugins relying on core classpath), which we can
> then add as exclusions in Dependabot config. But we may be surprised
> by helpful updates that we would never have thought to add to an allow
> list.
>
> --
> 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/CANfRfr3v5CgCcqf%3DMysY8N9-AOpOrFkqh%2BuNLxbSx%3DVw3Q%2Bynw%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/CANWgJS5uS7Y8PP76Lk2yZhSsACKhizRcEFOB9YCKLw6DRZK-0g%40mail.gmail.com.

[DISCUSS] Dependabot for Jenkins core (was:Re: Proposal: Automating dependency management for repositories inside the jenkinsci org)

[Baptiste Mathus]

Hi all,

I wanted to raise a discussion on this and thought I'd fork off this answer
from Jesse on Oleg's thread.

I see Jesse already configured Dependabot for Xstream:
https://github.com/jenkinsci/jenkins/commit/2440a34d8f2ba5626d734c735cb4fc63040c11de

Should we start adding all core components, like the parent pom, internal
or test tools like JTH,  and some dependencies we think are safe
(build-time things like Maven plugins, I assume)?

AIUI, we would be able to agree on an allowList approach? I.e. adding
specific dependencies we want auto-updated (excluding any that's unlisted).

Side note on this: I think if we agree to go this path, it would be great
to find a way modify the Core Pipeline so the essentials.yaml values are
sourced from some pom.xml (for ATH version) so Dependabot can understand
and update this too.
This way, we'd be getting automated updates for
https://github.com/jenkinsci/jenkins/blob/53f300d5ec07eb5efa3774d3f12455615d2f3450/essentials.yml#L4-L5
too, which bit us in the arse recently on the latest LTS prep IIRC.

WDYT?


IIUC, we could kinda take an allowList approach on specific components.

Le jeu. 21 févr. 2019 à 15:40, Jesse Glick  a écrit :

> On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev 
> wrote:
> > I propose to focus on development tools
>
> Since the primary use case is offering updates to plugin repositories,
> I would suggest including at least one example of `*-plugin`.
>
> The question is which dependencies ought to be eligible for upgrade. I
> do not think we want to update Jenkins core or plugin dependencies
> gratuitously, since this would limit availability of new releases with
> only modest productivity gain: more realistic functional tests, less
> distance from `master` to whatever `plugin-compat-tester` would use.
>
> Definitely we can freely upgrade the parent POM. I would be happy for
> such updates to be auto-merged in fact, so long as the build passes
> obviously.
>
> > pre-1.0 projects only
>
> Or just plugins that (a) have fairly low installation count, (b) are
> maintained by people actively participating in the trial.
>
> > More repositories can be added if somebody is interested to participate
> in the Dependabot evaluation.
>
> Sign me up!
>
> I _do_ need to make sure I get notifications of these PRs in
> Octobox.io, if they are not simply automerged. Merely watching a
> repository is not enough—GH has autosubscribed me to hundreds of
> repos, and the resulting thousands of notifications go to /dev/null.
> Maybe Dependabot can be configured to request me as a reviewer?
>
> --
> 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/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

[Baptiste Mathus]

Thanks!

(And I realize I didn't post the link I was meaning to...
https://www.jenkins.io/events/#event-calendar for anyone wondering)

Le jeu. 10 déc. 2020 à 22:57, Tim Jacomb  a écrit :

> Added all to the calendar
>
> On Thu, 10 Dec 2020 at 21:52, Tim Jacomb  wrote:
>
>> Daniel has granted
>>
>> On Thu, 10 Dec 2020 at 21:29, Mark Waite 
>> wrote:
>>
>>> +1 for Tim to be granted permission on the Jenkins calendar.
>>>
>>> On Thu, Dec 10, 2020 at 1:43 PM Tim Jacomb  wrote:
>>>
>>>> Sounds good to me
>>>>
>>>> I don't have any permissions on the calendar as far as I can see.
>>>>
>>>> Could someone add the dates please, and also grant me calendar
>>>> permissions?
>>>>
>>>> Thanks
>>>> Tim
>>>>
>>>> On Thu, 10 Dec 2020 at 14:44, Baptiste Mathus  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> (Possibly a question to Tim)
>>>>>
>>>>> Can we please consider updating the Jenkins events calendar with the
>>>>> next .1 (and possibly .2, and .3)?
>>>>> Or do we have any short term plan to change the LTS schedule?
>>>>> If so, and given we know this next LTS is going to be "big",
>>>>> <https://www.jenkins.io/blog/2020/11/10/major-changes-in-weekly-releases/>
>>>>> I guess we'd rather want to know earlier than later :-).
>>>>>
>>>>> Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose
>>>>> these dates will look like:
>>>>>
>>>>>- NEW.1 RC: 24th of February.
>>>>>- *NEW.1 release: 10th of March *
>>>>>- NEW.2 RC: 24th of March
>>>>>- etc.
>>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Baptiste
>>>>>
>>>>> --
>>>>> 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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%40mail.gmail.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Biftcw5b3b7HZanMbrc6n_mDO%3Dy%3DOfRkyu%3D_970FO_n74g%40mail.gmail.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> --
>>> 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/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtG6LEnC_XDuvwpU37qaa-b_d1DHWQvb6LPZ%2Bw2TaERLhg%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidynCBu5053wBUVdWBqtDu8R-Hsj4xc0QpDb1xMF19-Mw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BidynCBu5053wBUVdWBqtDu8R-Hsj4xc0QpDb1xMF19-Mw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CANWgJS4njaGhMCFJF4CGpiFGiumv5T8Vym2CMw8%3Dg25FOyA6Fw%40mail.gmail.com.

Add tentative LTS release dates for next baseline in Jenkins.io events calendar?

[Baptiste Mathus]

Hi all,

(Possibly a question to Tim)

Can we please consider updating the Jenkins events calendar with the next
.1 (and possibly .2, and .3)?
Or do we have any short term plan to change the LTS schedule?
If so, and given we know this next LTS is going to be "big",

I guess we'd rather want to know earlier than later :-).

Concretely, given 2.263.3 is slated for the 10th of Feb, I suppose these
dates will look like:

   - NEW.1 RC: 24th of February.
   - *NEW.1 release: 10th of March *
   - NEW.2 RC: 24th of March
   - etc.


Thanks!

-- Baptiste

-- 
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/CANWgJS4cmLsp_Cwau7pQEAEJgtUXDK0xodPz%3Dnff%3D8woftU1_A%40mail.gmail.com.

Re: Core Baseline Java8 -> Java11?

[Baptiste Mathus]

I agree but given the (often dangerously subtle) incompatibilities between
agents and controllers when they run a different jvm, we should do this
with a tight plan.

Maybe some of the features currently in version-column plugin should be put
inside the core so alerts and guidance are more systematic if agent is
running a different major version of the jvm than the controller's one.

Le ven. 4 déc. 2020 à 19:27, Tim Jacomb  a écrit :

> I think defaulting the docker images to java11 would be a good start
>
> On Fri, 4 Dec 2020 at 17:26, Baptiste Mathus  wrote:
>
>> I agree with Daniel's take: delay to do something for real not before mid
>> 2021.
>> And I think we can still definitely love forward in the meantime on a
>> plan.
>> Which this thread is great for brainstorming about (thanks Ulli).
>>
>> For instance, we did switch ci.j.i to java 11 already.
>> I would think we want to plan ahead, start having an administrative
>> monitor warning users for some months that the bump is coming if we detect
>> a java 8 jvm, etc.
>>
>> Is there anything else we could do to encourage more users to just
>> upgrade by themselves, so when we bump the default values we have like 30%
>> or less of instances running on java8?
>>
>>
>>
>> Le ven. 4 déc. 2020 à 17:35, Matt Sicker  a
>> écrit :
>>
>>> It may be important to note that requiring Java 11 to run Jenkins
>>> doesn't mean you can't still use it to build Java 8 (or older!)
>>> projects.
>>>
>>> From a user point of view, I'd prefer that we can at least ensure that
>>> Jenkins runs properly in the latest Java releases. Running a newer JVM
>>> brings with it all the performance improvements over the past few
>>> years, and it also natively supports TLS 1.3 which is fairly important
>>> for HTTPS as well as for securing inbound remoting agents. The
>>> HttpClient API is one of the nifty features provided since Java 11,
>>> too, as already mentioned. Project Loom may turn out to be incredibly
>>> useful for Jenkins. And then there's also potential that the JPMS API
>>> might be useful for enhancing plugin class loader isolation.
>>>
>>> On Fri, Dec 4, 2020 at 4:55 AM jn...@cloudbees.com 
>>> wrote:
>>> >
>>> > >  is there any advantages in java 11 your looking forward to
>>> >
>>> > Personally I would change my code to use a HTTP client library that
>>> has async support, SNI, (all the things you expect) and not rely on a third
>>> party API that does not have stellar backwards compatibility :)
>>> >
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
>>> >
>>> >
>>> > On Friday, December 4, 2020 at 9:03:57 AM UTC ga...@gavinmogan.com
>>> wrote:
>>> >>
>>> >> As a non java person, Is there any advantages in java 11 your looking
>>> forward to? ones that might encourage people to upgrade? I know streams and
>>> lambdas were nice in 8(?)
>>> >>
>>> >> its my understanding that most things should now compile with java
>>> 11, but not bumping the minimum version yet.
>>> >>
>>> >> Gavin
>>> >>
>>> >>
>>> >> On Fri, Dec 4, 2020 at 12:43 AM Ullrich Hafner 
>>> wrote:
>>> >>>
>>> >>> Ok, I understand that. I wasn’t aware that so may people are still
>>> using Java 8. My students just ask me every time they want to contribute to
>>> my Jenkins plugins why they still need to use that old Java version ;-)
>>> >>>
>>> >>> Am 04.12.2020 um 08:34 schrieb Tim Jacomb :
>>> >>>
>>> >>> I would be definitely +1 for switching defaults and encouraging
>>> people to use jdk11
>>> >>>
>>> >>> And not against updating the minimum version, people will move when
>>> they have to.
>>> >>>
>>> >>>
>>> >>> The problem is that Oracle will provide support until 2030, that
>>> means nobody will be forced in the near future…
>>> >>>
>>> >>> At my previous work we moved from 7 to 8 when we had to and it was
>>> no issue...
>>> >>>
>>> >>> We’ve been on 11 for awhile here...
>>> >>>
>>> >>> Java 8 is 6 years older at this point, yes a lots been backported
>>> but that doesn’t mean we should stay at it forever
>>&g

Re: ANN: Jenkins 2020 Elections - Results

[Baptiste Mathus]

Congrats and thanks to the committee for the hard work!

Le ven. 4 déc. 2020 à 13:15, Arnaud Héritier  a écrit :

> congratulations !
>
> On Thu, Dec 3, 2020 at 11:52 PM Oleg Nenashev 
> wrote:
>
>> Dear all,
>>
>> We have finished the 2020 elections. On behalf of the Jenkins community
>> and the elections committee, we congratulate all newly elected board
>> members and officers! These roles are an essential part of Jenkins'
>> community governance and well-being, and we are excited to see contributors
>> taking these roles.
>>
>> We would like to thank all candidates who participated this year. We had
>> 9 governance board and 3 release officer candidates: Andrey Falko, Baptiste
>> Mathius, Ewelina Wilkosz, Frederic Gurr, Gavin Mogan, Justin Harringa, Mark
>> Waite, Marky Jackson, Steven Terrana, Victor Martinez, and Zhao Xiaojie
>> (Rick). Regardless of the results, all of them are awesome community
>> leaders who actively participate in the Jenkins project and represent its
>> users. Their contributions are instrumental to the project’s success, and
>> we highly appreciate them. Thank you!
>>
>> Election results, effective on Dec 03:
>>
>>-
>>
>>Gavin Mogan  and Marky Jackson
>> will join Kohsuke Kawaguchi, 
>> Ullrich
>>Hafner and Oleg Nenashev on the Jenkins Governance Board
>>
>>-
>>
>>Tim Jacomb  will become the new Release
>>Officer 
>>-
>>
>>Marky Jackson  will become
>>the new Events Officer 
>>(uncontested)
>>-
>>
>>Olivier Vernin  will continue in the role
>>of Infrastructure Officer
>> for another
>>term (uncontested)
>>-
>>
>>Daniel Beck  will continue in the
>>role of Security Officer
>> for another term
>>(uncontested)
>>-
>>
>>Mark Waite  will continue in the role
>>of Documentation Officer
>> for another
>>term (uncontested)
>>
>>
>> We also thank Alex Earl, Alyssa Tong, R. Tyler Croy and Oliver Gondža who
>> are stepping down from their roles this year. All of them have been
>> long-time Jenkins community leaders, and we are looking forward to keeping
>> working with them.
>>
>> Raw election results can be found here: Governance Board elections
>> , 
>> Release
>> Officer Elections
>> .
>> If you are interested to learn more, please stay tuned for the announcement
>> blogpost which should land soon (pull request
>> ). There is also
>> a retrospective document available here
>> ,
>> any feedback and suggestions will be appreciated!
>>
>>
>>
>> Best regards,
>>
>> Jenkins 2020 Elections Committee
>>
>> --
>> 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/CAPfivLCpDDv57%3DmUvT-CnfZK2a%3DseJAHV9a_FLf%2BmJxWZoq%3D2w%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAFNCU-9uXd3WPqfYoG4cM%2BzufdoiVPBUQrtKA0FpBLNoYBj-QA%40mail.gmail.com
> 
> .
>

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

Re: Core Baseline Java8 -> Java11?

[Baptiste Mathus]

I agree with Daniel's take: delay to do something for real not before mid
2021.
And I think we can still definitely love forward in the meantime on a plan.
Which this thread is great for brainstorming about (thanks Ulli).

For instance, we did switch ci.j.i to java 11 already.
I would think we want to plan ahead, start having an administrative monitor
warning users for some months that the bump is coming if we detect a java 8
jvm, etc.

Is there anything else we could do to encourage more users to just upgrade
by themselves, so when we bump the default values we have like 30% or less
of instances running on java8?



Le ven. 4 déc. 2020 à 17:35, Matt Sicker  a écrit :

> It may be important to note that requiring Java 11 to run Jenkins
> doesn't mean you can't still use it to build Java 8 (or older!)
> projects.
>
> From a user point of view, I'd prefer that we can at least ensure that
> Jenkins runs properly in the latest Java releases. Running a newer JVM
> brings with it all the performance improvements over the past few
> years, and it also natively supports TLS 1.3 which is fairly important
> for HTTPS as well as for securing inbound remoting agents. The
> HttpClient API is one of the nifty features provided since Java 11,
> too, as already mentioned. Project Loom may turn out to be incredibly
> useful for Jenkins. And then there's also potential that the JPMS API
> might be useful for enhancing plugin class loader isolation.
>
> On Fri, Dec 4, 2020 at 4:55 AM jn...@cloudbees.com 
> wrote:
> >
> > >  is there any advantages in java 11 your looking forward to
> >
> > Personally I would change my code to use a HTTP client library that has
> async support, SNI, (all the things you expect) and not rely on a third
> party API that does not have stellar backwards compatibility :)
> >
> https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html
> >
> >
> > On Friday, December 4, 2020 at 9:03:57 AM UTC ga...@gavinmogan.com
> wrote:
> >>
> >> As a non java person, Is there any advantages in java 11 your looking
> forward to? ones that might encourage people to upgrade? I know streams and
> lambdas were nice in 8(?)
> >>
> >> its my understanding that most things should now compile with java 11,
> but not bumping the minimum version yet.
> >>
> >> Gavin
> >>
> >>
> >> On Fri, Dec 4, 2020 at 12:43 AM Ullrich Hafner 
> wrote:
> >>>
> >>> Ok, I understand that. I wasn’t aware that so may people are still
> using Java 8. My students just ask me every time they want to contribute to
> my Jenkins plugins why they still need to use that old Java version ;-)
> >>>
> >>> Am 04.12.2020 um 08:34 schrieb Tim Jacomb :
> >>>
> >>> I would be definitely +1 for switching defaults and encouraging people
> to use jdk11
> >>>
> >>> And not against updating the minimum version, people will move when
> they have to.
> >>>
> >>>
> >>> The problem is that Oracle will provide support until 2030, that means
> nobody will be forced in the near future…
> >>>
> >>> At my previous work we moved from 7 to 8 when we had to and it was no
> issue...
> >>>
> >>> We’ve been on 11 for awhile here...
> >>>
> >>> Java 8 is 6 years older at this point, yes a lots been backported but
> that doesn’t mean we should stay at it forever
> >>>
> >>> Sonarqube recently moved to require java 11 as an example of one
> development tool that has gone there before us
> >>>
> >>> Thanks
> >>> Tim
> >>>
> >>>
> >>> On Fri, 4 Dec 2020 at 00:33, Oleg Nenashev 
> wrote:
> 
>  Yes, the Java 11 adoption is still very low. It was around 30% last
> time I have seen the stats. Around 60% of users still run Java 8. With such
> a state it does not make sense to drop the Java 8 compatibility without
> really serious reasons which we IMHO do not have.
> 
>  On a separate note, a few weeks ago we discussed moving to Java 11 in
> the default container tags (`latest`, `stable` and so on). Even in this
> case we were far from having a consensus, because it would require a
> coordinate update of agents and controllers by many Jenkins users.
> 
>  BR, Oleg
> 
>  On Thursday, December 3, 2020 at 6:40:01 PM UTC+1 Mark Waite wrote:
> >
> > There are not.  Considering the relatively low adoption rate of Java
> 11, I'd personally resist a move to make Java 11 the baseline for quite a
> while unless there were some way to preserve and assure that Java 8
> continues to work as expected even with Java 11 as the baseline.
> >
> > On Thu, Dec 3, 2020 at 8:57 AM Ullrich Hafner 
> wrote:
> >>
> >> Are there already plans to move the Java baseline from Java 8 to
> Java 11 in the near future in Jenkins core?
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> send an email to jenkinsci-de...@googlegroups.com.
> >> To view this discussion on the 

Re: Jenkins 3.x

[Baptiste Mathus]

TBH, I'd just embrace the more and more common -mm-dd ish pattern of
releases.

It would kind of make this clearer to outsiders that the version numbers of
Jenkins are close to nothing related to stability but more a very regularly
recurring release pattern.

_Maybe_ I'd then agree with you for some new/adjusted version scheme *for
LTSes*, but not worth doing this for weeklies IMO.

It's *my* very personal opinion, fwiw.

-- Baptiste

Le mer. 25 nov. 2020 à 17:37, James Nord  a écrit :

> Hi all,
>
> with the recent weeklies we have a couple of changes (Acegi
> upgrade/table-to-div) that break compatibility in plugins.
>
> Whilst many open source plugins have been updated and made compatible with
> the old and new version by the people making the changes (and compatability
> layers have been added as far as possible), there can be closed source ones
> that we have no sight of that can be broken.
>
> Given this is an API compatibility breakage, I am wondering why don't we
> bump the version number to Jenkins 3.x  to signify the breaking API?
>
> Regards
>
> /James
>
> --
> 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/e58f72ae-ebc0-48dd-89f6-cb60f9ea0c85n%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/CANWgJS4jWRc3yfiyb_V9OJoVoXtGfBtWxfH5J58LL0rsz86jeA%40mail.gmail.com.

Re: Ask for security contact without maintainers approval

[Baptiste Mathus]

Adding Stefan in the thread, using the email I could find from the commits
on the gradle plugin.

@Stefan:

   - Do you still consider yourself a maintainer of the Jenkins Gradle
   plugin?
   - If so, can you review and approve
   https://github.com/jenkins-infra/repository-permissions-updater/pull/1708
   if fine?

Thanks!


Le mer. 18 nov. 2020 à 12:34, Manuel Ramón León Jiménez <
manuel.ramon.leon.jime...@gmail.com> a écrit :

> Hello.
>
> We, the *Foundation Security members* have filed several PRs to help on
> addressing security vulnerabilities on several plugins. You can find them
> with this filter:
>
> https://github.com/jenkins-infra/repository-permissions-updater/search?q=foundation_security_members_q=foundation_security_members
>
> We still have pending this one:
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1708
> The current maintainers didn't answer so far.
>
> Do you agree to move forward and add us as security contact? We can help
> in addressing security issues. We cannot commit to becoming maintainers
> though.
>
> Specially to Security members: Daniel Beck and others.
>
> Thank you.
>
> --
> 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/CAHHyvkN1TKwY-GQVZkO9RJ%2BKboN1jXiWoK69zs78B%2Bra%2ByWwXw%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/CANWgJS5w6CEBKQD1RNeqoPx23hYSMnHGrXGaia4xrmX3St%2BOVQ%40mail.gmail.com.

Re: LTS schedule winter break

[Baptiste Mathus]

+1, makes sense especially to preserve the lives of the people involved.

Le mer. 11 nov. 2020 à 12:05, Marky Jackson  a
écrit :

> +1
>
> > On Nov 11, 2020, at 12:48 AM, Daniel Beck  wrote:
> >
> > Hi everyone,
> >
> > We have an LTS release scheduled for December 30, which probably isn't
> useful: The RC testing period is from Dec 16 to Dec 30. Plus who wants to
> release things the day before NYE?
> >
> > I propose we add a two-week break between 2.263.1 release and 2.263.2
> RC, postponing all future RCs and releases by two weeks accordingly.
> >
> > Before:
> > Dec 2 - 2.263.1 Release
> > Dec 16 - 2.263.2 RC
> > Dec 30 - 2.263.2 Release
> > etc.
> >
> > After:
> > Dec 2 - 2.263.1 Release
> > Dec 30 - 2.263.2 RC
> > Jan 13 - 2.263.2 Release
> > etc.
> >
> > This should give us a useful RC testing period in early January. Since
> this is the .2 release, a slightly longer backporting period in December
> could help getting more fixes in for issues discovered in .1 as well.
> >
> > While the RC would be scheduled for Dec 30, it could always be prepared
> earlier if nobody would be around in late December to do it. If that
> doesn't work out and it is published in early Jan, that wouldn't be too
> much of a delay either.
> >
> > WDYT?
> >
> > Daniel
> >
> > --
> > 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/821EFEC7-55BA-475B-B977-1DCC1F559B82%40beckweb.net
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/F17409E1-8728-48F5-9DDF-76ADFA8CD3A6%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/CANWgJS5%3DYZZTpfK6RkJite1AVsipreddXrqYqR-sLyq1e6eKVQ%40mail.gmail.com.

Re: Archiving jenkinsci/jenkins-ace-editor repo

[Baptiste Mathus]

Sure. That does sound like the next step indeed.

I did advise to come through here just in case we've missed a use case for
it.
INFRA tickets get much less scrutiny.

Thanks!

Le lun. 2 nov. 2020 à 16:17, Jesse Glick  a écrit :

> On Mon, Nov 2, 2020 at 6:29 AM fque...@cloudbees.com
>  wrote:
> > I suggest archiving it.
>
> Just file an `INFRA` ticket in the `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/CANfRfr2iPBueHS0OsgUQKHVmD%2BLOvwmedSqZx5FJMn%2B3BZmsDQ%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/CANWgJS5hLE0EGUHaMuQk%2BkDkAooRXQxC7%3DVchXkVHK5TboYDBA%40mail.gmail.com.

Re: LTS baseline selection for the successor of 2.249

[Baptiste Mathus]

I agree. 2.263 seems like the least bad option.

Le ven. 23 oct. 2020 à 11:00, Oliver Gondža  a écrit :

> For now, we have no better candidate than 2.263. I suggest to accept it,
> with possibility to reevaluate in two weeks when the line is supposed to
> be initiated. We will keep it if nothing pressing pops up.
>
> On 23/10/2020 02.05, Mark Waite wrote:
> > That's correct.  The windows installer can't be built (yet) due to an
> > issue with password expiration and the Windows Docker container.
> >
> > Windows users can install prior weekly releases and use the "Upgrade
> > now" button inside Jenkins to install 2.263 on their Windows computer.
> >
> > On Thu, Oct 22, 2020 at 6:03 PM vsilv...@gmail.com
> >   > > wrote:
> >
> > It looks Windows release is not available -
> > https://github.com/jenkins-infra/jenkins.io/issues/3892
> >
> > On Thursday, October 22, 2020 at 2:48:45 PM UTC-7 Jesse Glick wrote:
> >
> > For what it is worth, 2.263 seems reasonable.
> > https://www.jenkins.io/changelog/ shows no user complaints so
> far.
> >
> > --
> > 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/30b38bff-19bc-4897-8d1a-d416b6664ef5n%40googlegroups.com
> > <
> https://groups.google.com/d/msgid/jenkinsci-dev/30b38bff-19bc-4897-8d1a-d416b6664ef5n%40googlegroups.com?utm_medium=email_source=footer
> >.
> >
> > --
> > 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/CAO49JtGyGEfOQ_0t15-LnqRVHWa31kVZ1QZ8dftkbeea8ohKQg%40mail.gmail.com
> > <
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtGyGEfOQ_0t15-LnqRVHWa31kVZ1QZ8dftkbeea8ohKQg%40mail.gmail.com?utm_medium=email_source=footer
> >.
>
>
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e59ae697-1d6d-055d-6cb7-0fe75f014897%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/CANWgJS7N8EjiQjg6zpPYYqbmG6wn3sTV2BGsBFWMHy9j-KCvHQ%40mail.gmail.com.

Re: Availability of Oliver Gondža in late 2020 and onward

[Baptiste Mathus]

Congratulations Oliver and, as per the phrase, thanks for all the fish ;).

Thanks a lot for your great contribution to the Jenkins Project. As a
father of 3 myself, without twins however, I certainly see your choice as a
wise one and can imagine what's in front of you for upcoming times.

Time to create the jenkinsci-parenting SiG and mailing list, it seems .

Cheers

Le mar. 20 oct. 2020 à 10:24, Oliver Gondža  a écrit :

> Hey Folks, After all those years with the project doing my best here and
> there (Release and LTS officer, reviewer and maintainer of a number of
> components), I have chosen to step back a bit. Partially as my focus is
> shifting away slowly, but mostly to direct my attention to my family and
> the twins expected to be born in a couple of weeks.
>
> Because of that:
>
> - I will not be a candidate for a Release officer nor a Board member
> this year.
> - I will no longer maintain jenkinsci/acceptance-test-harness.
> - The responsibility for leading LTS will be gradually transferred to
> some community member interested.
>
> I have truly enjoyed those 8 years in a company of so many talented and
> engaged engineers. It is not that I am leaving never to show up again,
> but this housekeeping is long overdue, and I owe doing this to the
> project and to myself.
>
> Thanks!
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/0a98fdb2-6f21-d55d-c197-0b32745628ed%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/CANWgJS654c9JyTktoruxLBOtOu%3DnOv306QmxoEY1nVjoHCt%3D7A%40mail.gmail.com.

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

[Baptiste Mathus]

I've just gone ahead and clicked on all repositories where the button was
available.

So given I don't have an easy way to request review from current active
maintainers.
*So Jesse or any maintainer: please review the list :*
https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Aapp%2Fdependabot-preview+user%3Ajenkinsci++%22Update+Dependabot+config+file%22+in%3Atitle

And look for any plugin you're maintaining.

AFAIU there's unfortunately no way to generate from this UI an automated PR
for all repositories and not just the ones who already had configured
Dependabot (now called "dependabot-preview").

But if there's interest, I'm happy to script something to file such a PR on
multiple repos.
I guess I'm not going to do for the whole org upfront just to avoid
potential people complaints. (?)

I'm not yet fully sure whether Oleg's concern on jenkins.version is still
current.
It _seems_ not anymore in the "dependabot native" app. But it's hard to
know whether this is something GitHub will add back parity for.
樂
And even so, I agree with Jesse that it would be better to request bumps
with some LTS version scheme requirement, rather than making them all
ignored. (See Oleg's PR earlier in this thread for context).

Anyway, looking at the positive side: thanks a lot Oleg again for making
this happen.
I think overall, whatever happens, keeping dependencies more up-to-date is
a great plus for the health of the Jenkins ecosystem.

-- Baptiste

Le lun. 19 oct. 2020 à 21:08, Ullrich Hafner  a
écrit :

> I think that this can be done globally: for each repository a PR will be
> generated. So in order to finish the transition the repo owner still needs
> to merge the PR. However, I do not find a button to run this for all
> repositories :-(
>
> > Am 19.10.2020 um 16:44 schrieb Jesse Glick :
> >
> > On Mon, Oct 19, 2020 at 7:57 AM Baptiste Mathus  wrote:
> >> If anybody still has the previous configuration, and would like to get
> an automated PR, please let me/us know and I can request it.
> >
> > I would certainly want this but have no idea which repositories I
> > might “own” which are configured with the preview app. Is there any
> > harm in just requesting the conversion PR for every remaining repo?
> >
> > --
> > 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/CANfRfr3Z_UnaBsWpg%2BwXhut7YOvZUG9X8dsTB-7EXfouOqypvA%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/7EE25BD9-977B-4D6A-A029-C8F1063DE0B4%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/CANWgJS5%3DnVdBGEMycgKC21f-uCt%3DV_EUKunCyvd4ipO-rPV-1Q%40mail.gmail.com.

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

[Baptiste Mathus]

Hi all,

FYI, as I was using the Dependabot admin UI, I just requested Dependabot to
file automated PRs on a number of plugins:

https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3Aapp%2Fdependabot-preview+user%3Ajenkinsci++%22Update+Dependabot+config+file%22+in%3Atitle

I was going to configure Dependabot on my buildtriggerbadge plugin, but
then realized Dependabot now has this nice feature to file automated PRs to
migrate from the previous Dependabot settings to the native one.

[image: image.png]

If anybody still has the previous configuration, and would like to get an
automated PR, please let me/us know and I can request it.

HTH
Cheers

Le jeu. 8 oct. 2020 à 13:29, Oleg Nenashev  a
écrit :

> I have started https://github.com/jenkinsci/.github/pull/40 with
> documentation notes. If anyone is interested to contribute and share your
> notes / best practices, please do so!
> Later we can move the page to
> https://www.jenkins.io/doc/developer/plugin-development/
>
> On Wednesday, June 24, 2020 at 11:03:25 PM UTC+2 Oleg Nenashev wrote:
>
>> FTR Dependabot is now embedded into GitHub. Probably it is a good time to
>> prepare official documentation
>> https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/
>
> --
> 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/af5db0c2-3be6-4efb-b017-c06cbe8ce912n%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/CANWgJS5a6_NedKRH%2BYreUWFohpXNgtyxOwO88uHqERDvTw_v3A%40mail.gmail.com.

Re: Jenkins Console Output: declarative pipeline + sh + python line-buffered

[Baptiste Mathus]

Hi,

Please use the users mailing list for such questions.

This list is dedicated to Jenkins development itself. Developing plugins or
Jenkins Core itself

Thank you

Thank you

Le dim. 18 oct. 2020 à 16:10, Danny Trunk  a écrit :

> Hello everybody,
>
> I've set up a declarative pipeline job using the sh step to run repo
> (which is a tool written in python - more information:
> https://source.android.com/setup/develop#repo)
> But I can't get stdout to be line-buffered.
>
> I've already tried the following:
> * `export PYTHONUNBUFFERED=1` in the sh block before calling repo.
> * setting PYTHONUNBUFFERED=1 in the environment block
> * using `stdbuf -i0 -e0 -o0 repo sync ...` instead of calling `repo sync
> ...` directly
> * combined all of the above
>
> I can't see any repo progress in the build console.
>
> By running the command manually in a bash I'm getting this output:
> ```
> root@jenkins-lineage:/var/jenkins_home/workspace/lineage# repo sync -j 2
> --force-sync
> remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   0% (1/774) LineageOS/android_artremote: Total 0
> (delta 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   0% (2/774) LineageOS/androidremote: Total 0 (delta
> 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   0% (3/774) LineageOS/android_bionicremote: Total 0
> (delta 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   0% (5/774) platform/build/katiremote: Total 0 (delta
> 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   0% (6/774) LineageOS/android_build_blueprintremote:
> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> Fetching projects:   1% (10/774) platform/developers/build^Caborted by user
> ```
>
> Here's an example of how I call repo:
> ```
> sh """#!/bin/bash
> repo init -u ${REPOSITORY_URL} -b ${params.BRANCH} --depth=1
> repo sync -j ${params.SYNC_THREADS} --force-sync
> """
> ```
>
> And here's the complete Jenkinsfile:
> https://github.com/dtrunk90/jenkins-lineage-docker/blob/master/Jenkinsfile
>
> So how I can get more information from repo in the Jenkins build console?
>
> Danny.
>
> --
> 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/M3FEIQ.X40JKJN2UW843%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/CANWgJS62whWj9SM_c0pk2YHfwTQR-O6S_YzjJry%2BHvSQe5GCSQ%40mail.gmail.com.

Re: Jenkins 2.249.1 LTS RC testing started

[Baptiste Mathus]

Ramon Leon (thanks!) created a Jira after the fact to track a regression
that got fixed in 2.251: https://issues.jenkins-ci.org/browse/JENKINS-63562
for this PR: https://github.com/jenkinsci/jenkins/pull/4881

It's marked lts-candidate, but since just 2 hours since this is also when
it got created: do you think it'd be eligible for backporting Oliver?

Thanks

Le jeu. 27 août 2020 à 17:53, Oliver Gondža  a écrit :

> Hello everyone,
>
> Latest LTS RC was made public and it is ready to be tested. Final
> release is scheduled for 2020-09-09.
>
> Please, report your findings in this thread.
>
> Download bits from
> http://mirrors.jenkins-ci.org/war-stable-rc/2.249.1/jenkins.war
> (sha256:b87ac2d3296149d5b28a40016f6394fb1246c6ae8ba18b50ce7b9458a9853992)
>
> Thanks!
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/964dcec6-7200-9d58-ee7f-3926852824ba%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/CANWgJS7%3DhvMxkNOfnjwJxDUoWFjAcO4Yg-Vk0akwYk%2Bo-7c%3Duw%40mail.gmail.com.

Re: Forked repositories in GitHub

[Baptiste Mathus]

+1. All for it.

Le mar. 18 août 2020 à 13:38, Daniel Beck  a écrit :

> Hi everyone,
>
> I'd like to propose a cleanup of 'fork' relationships of the repositories
> in the jenkinsci GitHub organization.
>
> Background:
> For many years, the plugin hosting process has forked existing
> repositories. The expectation was always that the new repo in jenkinsci was
> the canonical 'main' repository, but that wasn't enforced. For the past
> year or two, we've even asked maintainers to delete their repository after
> forking unless there were useful PRs and issues in there already, so that
> the jenkinsci repo became the 'main' repo (with occasional mishaps if
> someone else had forked before us).
>
> Some people enjoy the "branding" effect that having the source repository
> creates. But this comes with downsides: Sometimes GitHub code search
> doesn't work, depending on the popularity of the repository. Links to
> create pull requests sometimes don't work quite right, and INFRA-2697 notes
> that the GitHub CLI cannot really handle networks where a fork is the
> "main" repo, probably for the same reason. Having a different repo than
> what we consider canonical as the "root" repository confuses users trying
> to file pull requests or issues on GitHub. It'll get worse once GitHub adds
> repo-level discussions[1]. Basically, the more stuff is attached to a
> repository that isn't trivially cloned/mirrored to forks, the worse it gets.
>
> In terms of security, GitHub for quite some time did not support security
> warnings for forks. LGTM.com / GitHub Security Labs still does not
> recognize forked repositories. Earlier this year a security researcher
> recently used its CodeQL functionality to identify and submit fixes to
> pom.xml files referencing plain HTTP Maven repositories, but couldn't do
> that for forked repos. In many cases, the source repositories are much less
> active than the repo in jenkinsci, or the maintainers have moved on
> entirely, making this feature unavailable to (other) current maintainers,
> or the Jenkins security team.
>
> The way we create forks is simply not a well-supported use case.
>
> My proposal therefore is to "unfork" plugin and similar repositories in
> the jenkinsci organization. Only repositories that clearly are forks (e.g.
> some libraries not maintained by us) would remain forks.
>
> After checking with GitHub support, the following options exist:
>
> 1. It is possible to invert the fork relationship. This requires approval
> from both repo owners (i.e. jenkinsci and whoever we forked from).
> 2. It is possible to cut the fork relationship. This requires approval
> from the forked repo owner (i.e. jenkinsci).
>
> And while it is technically possible to re-attach repos to a network /
> merge networks, GH support would rather not do that.
>
> Therefore I propose we implement the following steps:
>
> 1. We try to contact, wherever possible, whoever we forked from, and ask
> them to contact GitHub support. I'll grant blanket permission on behalf of
> jenkinsci and will tell everyone the support ticket number to reference so
> this goes as smoothly as possible.
> 2. We wait a while while folks ask GH support for an inversion of the fork
> relationship.
> 3. We ask GitHub support to cut the fork relationship of everything that's
> left over.
>
> Additionally, we should change the hosting process to work with repo
> transfers, or creation of repos without the fork relationship. That can be
> done at any time though; as even now we don't really want that fork
> relationship we create to exist.
>
> To understand the scope of this, I've written a script that periodically
> updates a list of forked repositories in jenkinsci, you can see the result
> at
> https://www.jenkins.io/doc/developer/publishing/source-code-hosting/forks/
>
> One potential problem are plugins that are actively maintained outside the
> jenkinsci organization and only have an outdated fork in jenkinsci that
> isn't being used. I think it makes sense to ask maintainers to move their
> activity into jenkinsci (including perhaps a complete repo transfer to
> retain issues and PRs). If they refuse, rather than cut the fork
> relationship, we could just delete our unused fork. (While this touches on
> plugins maintained exclusively outside jenkinsci, I consider that general
> topic to be a separate conversation. Please keep this thread focused on
> this proposal.)
>
> Thoughts?
>
> Daniel
>
> 1:
> https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Re: Jenkins 2.235.4 LTS RC testing started

[Baptiste Mathus]

IIUC the most important, and quite easy, thing they could be done here
before we can also have the right thing on server side is for Oliver to
publish the hash for the local file he uploaded?

This way even if someone was able to midm the http:// server folks could
check they're testing the expected binaries?

WDYT ?

Oliver, are you able to add the computed hash in this thread?

Thanks

-- Baptiste

Le mar. 11 août 2020 à 17:24, Mark Waite  a
écrit :

>
> On Tue, Aug 11, 2020 at 8:55 AM 'Björn Pedersen' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> It looks like the certificate does not  cover all domains that  are
>> currently server:
>>
>> This server could not prove that it is mirrors.jenkins-ci.org; its
>> security certificate is from pkg.origin.jenkins.io. This may be caused
>> by a misconfiguration or an attacker intercepting your connection
>> As it is a letsencyrpt certifacte, maybe just adding the domain (
>> https://certbot.eff.org/docs/using.html#changing-a-certificate-s-domains
>> if using certbot)  could help?
>>
>>
>   Unfortunately, there's significantly more involved in the transition
> than adding an SSL certificate to the domain.
>
> That location is the root of the Jenkins mirrors.  The mirroring software
> we use does not support HTTPS.  We're in the process of switching to new
> mirroring software that supports HTTPS.
>
>
>> Björn
>> johno.c...@gmail.com schrieb am Montag, 10. August 2020 um 19:33:23
>> UTC+2:
>>
>>> Would be great if in the future you could provide a https link and
>>> hashes of the binary. Sadly I did a little bit of digging and found this
>>> ticket.. https://issues.jenkins.io/browse/INFRA-266
>>>
>>> J
>>>
>>> On Mon, Aug 10, 2020 at 7:25 PM Johno Crawford 
>>> wrote:
>>>
 Hi Oliver,

 Any https servers available to download the latest LTS RC?

 J

 On Sun, Aug 2, 2020 at 9:30 AM Oliver Gondža  wrote:

> Hello everyone,
>
> Latest LTS RC was made public and it is ready to be tested. Final
> release is scheduled for 2020-08-12.
>
> Please, report your findings in this thread.
>
> Download bits from
> http://mirrors.jenkins-ci.org/war-stable-rc/2.235.4/jenkins.war
>
> Thanks!
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/84782d44-dd40-619f-9f6f-2585455bc89d%40gmail.com
> .
>


 --
 Johno Crawford

>>>
>>>
>>> --
>>> Johno Crawford
>>>
>> --
>> 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/c632c50b-fe72-4f4e-84fb-1f2e47c26901n%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/CAO49JtGs4EO1gAk_P%3DVXkytxrmzzq7AkqSewrKr4yTd22k_rRw%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/CANWgJS45HWB7uSQU04B_3FdxvDzVNyLShv_727gtCCpj56QvPg%40mail.gmail.com.

Re: MSBuild Jenkins | Adopt a Plugin

[Baptiste Mathus]

Thank you for the proposal Joseph.

Going with this, I would like to propose our help wrt. security
maintenance.
Our team at CloudBees will be able to react on security issue reports, by
definition time-sensitive.
We have done this already for a number of plugins:
https://github.com/jenkins-infra/repository-permissions-updater/search?q=foundation_security_members_q=foundation_security_members

I will propose the PR for this.

If anybody sees a problem with this, please let me know.

Thanks!

Le mer. 5 août 2020 à 14:03, Oleg Nenashev  a
écrit :

> Hi Joseph,
>
> Thanks for the interest! +1 from me.
>
> I have just noticed that there is no pull requests fro you submitted for
> this plugin. It is not a blocker for ownership transition according to our
> process. At the same time, it would be great if you could summarize your
> plans for this plugin.
>
> Best regards,
> Oleg
>
> On Tuesday, August 4, 2020 at 1:46:28 AM UTC+2, Joseph Akroush wrote:
>>
>> Hello,
>>
>> My name is Joseph Akroush. I am interested in becoming a maintainer for
>> the MSBuild Jenkins plugin.
>>
>> Link to plugin: https://plugins.jenkins.io/msbuild/
>> GitHub profile: https://github.com/josephakroush
>> 
>> Jenkins infrastructure account id: akroushj
>>
>> I look forward to hearing from you.
>>
>> Thank you!
>>
> --
> 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/41a4004c-5760-4929-b33d-aede3011eacco%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/CANWgJS5-3i-2io05O-WwKei-nsCnYj12YzhbFKd2Q7BqA0tHBg%40mail.gmail.com.

Re: Proposal: Release Jenkins weekly on Tuesday

[Baptiste Mathus]

I'm all for making Mark and other active contributors' lives simpler.
So proposed solution to release on Tuesdays seems easy enough as a
short-term one.

For longer-term, I agree fully with Tim.
This should probably be automated and changelog be ready before merging.
Maybe we could use some automation and auto-merging way, like the tooling
would merge automatically after 24 hours of "ready-for-merge" label + some
TBD check on the changelog readiness itself before merging?

Le lun. 18 mai 2020 à 21:27, Tim Jacomb  a écrit :

> Or we could possibly move weekly changelog to GitHub release only?
>
> I think that would make it it more less effort by being automated + slight
> tweaks on top
>
> Thoughts?
>
> On Mon, 18 May 2020 at 20:18, Daniel Beck  wrote:
>
>> Easy fix: Whoever wants to merge something on a weekend is responsible
>> for updating the changelog.
>>
>> If this isn't done, and you've merged fixes a few times, you lose commit
>> access.
>>
>>
>> > On 18. May 2020, at 20:55, Mark Waite 
>> wrote:
>> >
>> > I worry that creating the changelog on Friday with release on
>> > Monday seems like it would either preclude merge on Saturday and on
>> Sunday
>> > (for those who wish to do so)
>>
>> --
>> 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/9E86865E-831C-4B5F-A4A2-77E6AB9882EB%40beckweb.net
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bif7em3VUMjH9v_J%2BC%2B-8J4ds9AEyYtjJWORB6BgZjqMtA%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/CAPyTVp3A%2BEcg7C58Zmi%2BeT5jvic5bDRyVqhKbTH8tL5uXse5Ww%40mail.gmail.com.

Re: Governance and Jenkins is the Way on Jumbotron

[Baptiste Mathus]

+1 obviously :). Nice idea

On Tue, May 5, 2020 at 9:15 AM Oleg Nenashev  wrote:

> +1 from me. It is a good opportunity to get user stories and promote the
> Jenkins project.
>
> On Tuesday, May 5, 2020 at 7:58:07 AM UTC+2, Tim Jacomb wrote:
>>
>> +1
>>
>> On Tue, 5 May 2020 at 02:07, Mark Waite  wrote:
>>
>>> The "Jenkins is the Way
>>> " blog post
>>> invites users to share their Jenkins stories.  I would like to see us
>>> highlight the collection and highlighting of Jenkins experiences even more.
>>>
>>> One way to highlight further is to add the "Jenkins is the Way" blog
>>> post to the Jumbotron on the front page of the jenkins.io site.  I've
>>> added it to the governance meeting agenda for this Wednesday.
>>>
>>> As one way of reducing time spent in the governance meeting on the
>>> topic, I'd like to gather comments from the mailing list prior to the
>>> meeting.
>>>
>>> Would you support including "Jenkins is the Way" in the Jumbotron
>>> rotation for a period of 30 - 45 days?
>>>
>>> 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 jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/112ac905-7ddd-4961-a731-21c1e02fe0de%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/d780abcf-db3d-477e-9073-5e53ce702ea6%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/CAPyTVp1arFU%3DC94%2BGAeD118jw07-zdb6h4zxE%2BBJYTgNUkUbeA%40mail.gmail.com.

Re: LTS baseline selection for the successor of 2.222

[Baptiste Mathus]

I would also vote for 2.234 for the UI improvements that I think the UX SiG
would love to see used more widely and get more feedback about.

Thanks!

On Wed, Apr 29, 2020 at 2:00 PM Tim Jacomb  wrote:

> My preference would be 2.234,
>
> It has the most system read features in it which  would be great to
> announce as part of the next LTS
>
> Also 2.233 has the button re-work which really should make it in imo (and
> 2.234 with the help icon changes)
>
> Thanks
> Tim
>
> On Wed, 29 Apr 2020 at 11:44, Oliver Gondža  wrote:
>
>> In accordance we recently approved process changes, we are doing next
>> baseline section two weeks earlier in the cycle. Let's voice the
>> baseline candidates and concerns so we have the candidate by next
>> Governance meeting at 2020-05-06.
>>
>> My preferable choices would be 2.232 as the next release have introduced
>> 2 known regressions. They are resolved in 2.234 so that would work as a
>> second option, too.
>>
>> 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 jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/ef5d8ebf-1812-a451-1c75-d9b7344b430d%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/CAH-3BiciX%2BFfXwFKGLSunK5G%2Bk1tq5VEZsZgGRZiBMFJeK2L-w%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/CAPyTVp26_NmDSqSFzid4cqRMaii%2B%2B0RWmAsLSEWmzaHeuVCtew%40mail.gmail.com.

Re: Plugin Licenses

[Baptiste Mathus]

Agreed. It's never been clarified enough.

And this is a problem, because contrary to what we can read sometimes, the
default license is proprietary, not OSS.

On Fri, Apr 24, 2020 at 12:54 PM Oleg Nenashev 
wrote:

> +1 for immediate depublishing. Usage of non-OSI licenses in plugins
> potentially causes legal risks for Jenkins users.
>
> Maybe we should also start forcing an explicit license specification in
> pom.xml and LICENSE for future plugin POM versions (5.0?). It has been
> discussed a few times in the previous years, but IIRC we did not add
> mandatory checks
>
> --
> 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/f203c1b1-30a8-4cd4-ad90-8577b301e971%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/CAPyTVp0ow20VCaJ7PdAhfBQYMdj4%3DBKz%2Bk-9LN8JdMU1SQMWLw%40mail.gmail.com.

Re: Request to be plugin co-maintainer of Kubernetes-plugin

[Baptiste Mathus]

Hi Marky, please file a PR on the permissions repo. Make sure to reference
the JIRA ticket so we fast forward with Vincent approval.

Thanks!

On Mon, Mar 23, 2020 at 10:29 AM Marky Jackson 
wrote:

> 
> Hello all.
> I am putting in a request to be added as a co-maintainer of the following
> plugin: https://github.com/jenkinsci/kubernetes-plugin
>
> I have spoke to both Carlos Sanchez and Vincent Latombe, who have approved.
> I have also open the following jira:
> https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/INFRA-2547
>
> Thank kindly.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/8ACEAD43-B72E-439B-9BEA-0DFA8A343E8D%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/CAPyTVp0ftjLsc7bKY3Sjk7qpLsW4QJ4B--qNXEHEy_RmmyMFKw%40mail.gmail.com.

Re: Proposal: Emeritus maintainers

[Baptiste Mathus]

Le lun. 2 mars 2020 à 13:40, Stephen Connolly  a
écrit :

>
>
> On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:
>>
>>
>>
>> On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly 
>> wrote:
>>
>>> If all maintainers of a plugin are emeritus and someone wants to claim
>>> ownership then the emeritus maintainers can short-circuit the transfer of
>>> ownership rather than having to wait out the full period.
>>>
>>
>> Seems like this can trivially be accomplished by amending the usual
>> adoption process (2 week timeout) to special-case "I used to maintain
>> this". We've actually done that already in the past, when the last release
>> pre-dated the cutoff date I used to initialize the permission files: The
>> requester told us they maintained the plugin back 2012, they'd like to get
>> permissions back. Nobody else was around to tell us "no" (i.e. no other
>> co-maintainers recorded), so it was just done.
>>
>> My main question here is how this would impact plugins with active
>> maintainers. If you remove yourself from credentials plugin, it is
>> currently considered to be maintained jointly by seven people. Do you
>> expect to get permissions back without any approval from any of them, if
>> you decide to?
>>
>
> If there are active maintainers, they can veto within a fixed period of
> time (say 72h or 1 week or whatever people want), but I think it would have
> to be a veto not an approval.
>

Overall +1 with a strong concern from my side on the 'new and active
maintainers' respect aspect.

I think this is fine to move into a fast-forwardable veto system, however
only taking in account a duration.
E.g. such "emeritus" maintainers would be able to get access back in a
fast-track way only if they can show an activity in the last 12 months.
IOW I do not think someone who was not active in the last, say, 2 years
should be able to get access back in less than the default timeout of 2
weeks.


> --
> 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/cb6de16c-7621-4244-a373-12dbbb62cd4c%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/CANWgJS4p3L1wqc%2Bc2LpWqjW9yNjb5UGMCsWdzx3Qvb73gVxREw%40mail.gmail.com.

Re: LTS baseline selection

[Baptiste Mathus]

Curious @Tim:
did you also:

   - enable the new header UI?
   - enable JEP-223?

Thanks!


On Wed, Feb 26, 2020 at 11:02 AM Tim Jacomb  wrote:

> We've been running 2.222 in production since first thing Monday,
>
> No issues so far,
>
> We enabled the global background build discarder, it ran for about 9 hours
> on the first run and cleared up ~200GB of space,
> We're very happy with the disk cleanup feature in 2.221 (thanks DB)
>
> Thanks
> Tim
>
> On Tue, 25 Feb 2020 at 22:59, Daniel Beck  wrote:
>
>>
>>
>> > On 25. Feb 2020, at 16:44, Oleg Nenashev 
>> wrote:
>> >
>> > There is also  https://issues.jenkins-ci.org/browse/JENKINS-60409
>> which needs to be investigated for the new LTS candidate. Looks like the
>> default Jetty behavior changed, and it may impact some users when they
>> upgrade to the new baseline
>>
>> Irrelevant for this thread, as that issue affects every weekly release
>> newer than the current LTS baseline. Might need upgrade docs or an
>> expedited fix + back port but that applies to every potential LTS baseline
>> choice.
>>
>> --
>> 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/7E8CB82D-2A1F-4A02-B42A-2AE0920CD822%40beckweb.net
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieKEt0Jv3RZb19yWmBZNTbyr%2Bmf%2BAmjP1SxeO3XdEvGfA%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/CAPyTVp0kF6zx%2BpmR9LCN7XS8iTfi6aS86TGDR3j%3DZMXfRSHzTg%40mail.gmail.com.

Re: LTS baseline selection

[Baptiste Mathus]

On Tue, Feb 25, 2020 at 12:33 AM Jesse Glick  wrote:

> On Mon, Feb 24, 2020 at 4:37 PM Oliver Gondža  wrote:
> > the baseline candidates
>
> Reference: https://jenkins.io/changelog/
>
> > in advance to speed up the discussion in governance meeting.
>
> Are baselines still selected during governance meetings? I thought
> that had switched to the list.
>

I *think* the discussion happens here a lot, but the final /stamp/ after
the trend/discussion/decision here is still done during gov meeting (still
makes sense IMO).



> --
> 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/CANfRfr1C4wg1EiT18OuyG3Mi3WeZspgwtUuqpME2L_7P-O%2B_CQ%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/CAPyTVp3jDBk-QahuuwhkVbLK_9BJSJRMNq7ZFBNX5qp7T1LcFw%40mail.gmail.com.

Re: Proposal: Jenkins Core PR reviewers team

[Baptiste Mathus]

+1 to add Marky too.

On Tue, Feb 18, 2020 at 9:59 AM Tim Jacomb  wrote:

> +1 from my side
>
> On Tue, 18 Feb 2020 at 08:10, Francisco Javier Fernandez <
> fjfernan...@cloudbees.com> wrote:
>
>> Oleg, Marky, +1 from my side. Any help is always more than welcome!
>>
>> El domingo, 16 de febrero de 2020, 19:59:06 (UTC+1), Marky Jackson
>> escribió:
>>>
>>> Thank you kindly Oleg, please do get well. Sending healing thoughts.
>>>
>>> On Feb 16, 2020, at 10:30 AM, Oleg Nenashev  wrote:
>>>
>>> Hi Marky. As we discussed in PM, I have an action item to follow-up on
>>> that. Sorry that I cannot provide the response time you expect, but I was
>>> mostly off over past days (sick leave). I will do my best to propose formal
>>> criteria for newcomer core PR reviewers next week. The informal criteria
>>> before was several months of activities in the core and a number of
>>> substantial contributions.
>>>
>>> If others vote in favor of adding Marky to the Core PR Reviewers, I am
>>> +1 w.r.t that.
>>>
>>> BR, Oleg
>>>
>>>
>>>
>>> On Sun, Feb 16, 2020, 19:10 Marky Jackson  wrote:
>>>
 I wanted to circle back around on this

 On Thursday, February 13, 2020 at 4:48:44 PM UTC-8, Marky Jackson wrote:
>
> I am happy to be included and thank you Gavin
>
> On Feb 13, 2020, at 4:46 PM, 'Gavin Mogan' via Jenkins Developers <
> jenkin...@googlegroups.com> wrote:
>
> Sorry ya'll, with the new approved core developers, I'm going to step
> down as a core-pr-reviewer. Its a little overwhelming to me, and I'm not
> comfortable with core/java, but i'm still up for helping out randomly 
> where
> i can, especially for plugins, and web/javascript stuff. I'll lurk 
> randomly
> elsewhere.
>
> (this leaves room for Marky though)
>
> On Sun, Feb 2, 2020 at 1:04 AM Marky Jackson 
> wrote:
>
>> I love a good challenge.
>> Let’s hold off on this request and I will get some general reviews
>> under my belt for some time and reapply at a later date.
>> Thanks kindly for the consideration.
>>
>> On Feb 1, 2020, at 11:53 PM, Daniel Beck  wrote:
>>
>>
>> Extrapolating from the introduction of this team would mean people
>> should first be regular core PR reviewers. There's no process barrier to
>> just start doing that.
>>
>> Right now,
>> https://github.com/jenkinsci/jenkins/pulls?utf8=%E2%9C%93=is%3Apr+involves%3Amarkyjackson-taulia
>> looks a little empty.
>>
>> --
>> 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/CAMo7PtLNMKCiby_hamQ%2BpUBZyVZBzyTphw8LiTE1Y1xsbz9EOw%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/6001CF17-C6EB-4F86-ABF0-3754580C0BE3%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 jenkin...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusuUMUQuMqXYwbQ6vf%2BqaXgNzT9cg_5M9QYJzh7c%3DVbWg%40mail.gmail.com
> 
> .
>
>
> --
 You received this message because you are subscribed to a topic in the
 Google Groups "Jenkins Developers" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/jenkinsci-dev/0sdrcSOQW64/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 jenkin...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/46d147a4-3f81-4eea-93ad-3a355329eb28%40googlegroups.com
 
 .

>>> --
>>> You received this 

Re: AWS Data Engineer.

[Baptiste Mathus]

Triple facepalm...

This one is my fault, so sorry. I went too fast and clicked the "always
approve", even worse.

Can someone with more permissions check that this user's next post doesn't
get through too please?

My apologies again.
Thanks

Le ven. 14 févr. 2020 à 19:31, Sai Kumar B  a
écrit :

> Job Title:- AWS Data Engineer.
> Location:- Charlotte, FL.
> Duration:- Long Term Contract.
> Job Description:-
> -> Experience In Designing And Deploying An AWS-Based Application
> (Native/Re-Factored), #Python, #Scala, #Spark, #Oozie, #Big Data.
> -> Expertise In The #Core AWS Services, Uses #Automation And #Architecture
> Best Practices.
> -> Proficiency In Designing, Developing, And Deploying Cloud-Based Big
> Data Solutions Using #AWS.
> -> Experience With Developing And Maintaining Applications Written For
> Amazon Simple Storage Service, Amazon Simple Queue Service,
> Amazon Simple Notification Service, Amazon Simple Workflow, API
> Gateway Service, AWS Elastic Beanstalk, and AWS Cloud Formation.
> -> Proficiency In #Amazon Compute And #Storage Instances.
> -> Experience With #S3 Server Side Encryption, #IAM, and #Policy,
> #CloudTrail, #CloudWatch.
> -> Experience On #EMR And #Glue.
> -> Experience Setting Up #Kinsesis Streams And Integrating Them With #CDC
> (Attunity Preferred).
> -> 5+ Years Working With #Big Data (Hadoop, Cloudera, HBase).
> -> Proficiency On High Available, #Fault Tolerant, And #DR Architecture.
> -> Good Working Knowledge And Experience Working With Databases Like
> #DynamoDB, #S3, #Postgre.
> -> Experience On #DevOps CI and #CD Using #Jenkins or #Bamboo or #Code
> Deploy AWS Developer, #Solution Architect Certified A Plus.
> -> Experience With #Atlassian Stack Highly Preferred.
>
> Thanks & Regards,
> B Sai Kumar,
> Email I.D:- saiku...@creativestaffing.in
> Phone Number:- +13153557845.
>
> --
> 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/245d4d11-fc18-4c37-a37b-ed4d5a65d3a0%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/CANWgJS5%3DV6qsVq8o%2B4yv-6iqTD-jiWA1KHqK3Qx%3Dz_z7FPRtVg%40mail.gmail.com.

Re: Presenting frontend toolchain changes

[Baptiste Mathus]

To circle back, FYI everyone the PR to remove JS-Builder got merged towards
2.217.

Feel free to reach out to us at the Jenkins UX SiG group if you have any
question, or want to help move the initiative faster :)

There's now also a WIP PR to modernize the header:
https://github.com/jenkinsci/jenkins/pull/4463 reviews and feedback welcome.

-- Baptiste



Le ven. 10 janv. 2020 à 17:48, Felix Queiruga  a
écrit :

> Quick update: I have created the draft PR with its corresponding JIRA task
> (https://github.com/jenkinsci/jenkins/pull/4425)
>
> On Friday, January 10, 2020 at 11:52:20 AM UTC+1, Oleg Nenashev wrote:
>>
>> +100 for switching from Jenkins JS Builder to a standard Webpack.
>> According to experiments with jsbuilder it is pretty difficult to use this
>> tool, especially for those ones who are not Javascript experts. Webpack is
>> at least a standard tool, so it will be more convenient for newcomer
>> Javascript contributors.
>>
>> I do not have strong opinion about JEP for the Jenkins core. IMHO it is
>> not strongly necessary there, because the implementation it is not exposed
>> to plugin developers. If we go further and introduce a new
>> framework/tooling instead of Jenkins JS Builder for plugins, then a JEP
>> would be really nice.
>>
>> Some comments about the changes:
>>
>>1. Once we have this implemented for the core, it would be nice to
>>add a banner to https://github.com/jenkinsci/js-builder and
>>https://github.com/jenkinsci/js-samples so that potential users see
>>references to the new flow
>>2. I would really be happy to see https://github.com/jenkinsci/js-libs 
>> reworked
>>or removed, but IIUC it is out of the scope (same for JS samples?
>>https://github.com/jenkinsci/js-samples)
>>   - They were already deprecated by Jenkins JS Builder:
>>   
>> https://github.com/jenkinsci/js-samples/blob/master/step-04-externalize-libs/HOW-IT-WORKS.md#configure-node-build-to-externalize-dependencies
>>   - We already have examples when plain NPM or Yarn are used in
>>   plugins. I'd guess webpack would be pretty similar
>>
>> Best regards,
>> Oleg
>>
>>
>> On Friday, January 10, 2020 at 11:22:37 AM UTC+1, Felix Queiruga wrote:
>>>
>>> I'll file the draft PR then.
>>>
>>> I already had in mind those TODOs that you mentioned. I wanted to get
>>> them done before filing the PR.
>>>
>>> On Thursday, January 9, 2020 at 8:18:31 PM UTC+1, Jesse Glick wrote:

 On Thu, Jan 9, 2020 at 1:10 PM Felix Queiruga 
 wrote:
 > The branch can be found at
 https://github.com/fqueiruga/jenkins/tree/replace-jsbuilder-with-webpack.
 Keep in mind that it is a WIP

 You may want to file it as a draft PR—get early CI and have a place
 for early review comments to be placed.

 The diff is mostly beyond my comprehension, but as a general matter

 · avoid whitespace-only changes (revert ones you have made already,
 and configure your editor to not touch lines of text unless you are
 actually editing them)
 · delete rather than comment out obsolete sections of code

>>> --
> 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/3f25ca63-5e16-426e-b7fe-f7813efa95df%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/CANWgJS5MAceCO9zhW%2Bxu%3DE5ENvEeJmJpwO3xSpjYojHRcSTwsg%40mail.gmail.com.

Re: PROPOSAL: Remove network discovery services

[Baptiste Mathus]

Le jeu. 30 janv. 2020 à 20:10, Tim Jacomb  a écrit :

> +1 on removing it, is there actually going to be anyone using it who is
> updating their Jenkins version? I.e is a plugin needed?
>

Would it be worth and possible writing a jep-214 Telemetry impl to catch
stats about this use? (Though it'd take a big time to be used, once people
upgrade to it, but at least we'd have some trend).


> On Thu, 30 Jan 2020 at 19:50, Slide  wrote:
>
>> I'm +1 on this, reducing the attack footprint for core is a good idea.
>>
>> On Thu, Jan 30, 2020 at 11:41 AM Jeff Thompson 
>> wrote:
>>
>>> On 1/30/20 11:25 AM, Jesse Glick wrote:
>>>
>>> On Thu, Jan 30, 2020 at 11:47 AM Jeff Thompson  
>>>  wrote:
>>>
>>> the capabilities could be pulled out of core into a plugin
>>>
>>> That was the longstanding proposal in JENKINS-33596.
>>>
>>> I think it's time to act on it.
>>>
>>> The key to implementing it in a plugin is to have someone who relies on
>>> it maintain it. If swarm uses it maybe someone involved with that could
>>> take it on. I'd be willing to help get things going with that, but not to
>>> maintain it. If nobody is interested enough for that, we should kill it off.
>>>
>>> Jeff
>>>
>>> --
>>> 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/e8f4603d-a953-10f8-0eb0-8cada6eaae36%40cloudbees.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/CAPiUgVc5Rijvp9OnktyfAsG8M2SrrMO0UwUR%2BTHwBm97pYCBaA%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifRQoyW2ECh1b4dV4axLtW6PzoK2WAJGOWJ%2BLE-3VcmVA%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/CAPyTVp0v-ja%2BaDkxiejjMJm0OdMYr87nrWwRvv2R9j3vergNfw%40mail.gmail.com.

Re: Request to add Marky Jackson as YouTube and twitter admin

[Baptiste Mathus]

+1 from me, obviously :). Marky is an active member of the community and
any help is warmly welcomed.

Thanks!

On Mon, Jan 20, 2020 at 3:20 PM Marky Jackson 
wrote:

> Hello all!
> This is a request to add me (Marky Jackson) to the admin of twitter and
> youtube. I have filed the following jira tickets in conjunction with JEP-10
> and JEP-13:
>
> https://issues.jenkins-ci.org/browse/INFRA-2431
> https://issues.jenkins-ci.org/browse/INFRA-2432
>
> The PR for my cla is here: https://github.com/jenkinsci/infra-cla/pull/79
>
> Thank you kindly in advance.
>
>
> --
> 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/fcc5bee3-27bc-4994-ac3b-588b32afa62d%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/CAPyTVp2jyMhmMd%3DN%2B-zz_oMUHWkms4rVhsNrjnxpkgdDbjjdNQ%40mail.gmail.com.

Re: org.jenkinsci.test.acceptance.plugins.warnings_ng.Assertions, java cannot find symbol

[Baptiste Mathus]

Can you paste somewhere the exact error?
Also which Java and Maven versions are you using?

Cheers

Le lun. 20 janv. 2020 à 03:41, Weiqingli Li  a
écrit :

> Hi,
>
> I am a QA and new for Jenkins. I pulled Jenkins Automation Harness and
> tried to compile. There is a compile error in
> WarningsNestGenerationPluginTest.java.
> Can not find
> symbol org.jenkinsci.test.acceptance.plugins.warnings_ng.Assertions.  Can
> anyone give me a hint?
> Thanks and have a nice day.
>
>
> Steven Li
>
> --
> 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/835319da-2243-44e8-ab25-8d83e3b8bf5d%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/CAPyTVp16aYxkXf-Pbt%3DhhiagP-hjn057xitsa4gZC8fLPjRukA%40mail.gmail.com.

Re: S3 plugin maintainership status

[Baptiste Mathus]

To circle back, here's the permission PR, thanks Evaristo for filing it!

https://github.com/jenkins-infra/repository-permissions-updater/pull/1400

Le mer. 15 janv. 2020 à 11:15, Francisco Javier Fernandez <
fjfernan...@cloudbees.com> a écrit :

> I'm interested as well
>
> Github: fcojfernandez
> JIRA: fcojfernandez
>
> El miércoles, 15 de enero de 2020, 11:14:13 (UTC+1), Evaristo Gutierrez
> escribió:
>>
>> Thanks Oleg and everyone!
>>
>> Github: varyvol
>> JIRA: egutierrez
>>
>> On Monday, January 13, 2020 at 5:01:28 PM UTC+1, Evaristo Gutierrez wrote:
>>>
>>> Hi all,
>>>
>>> Nearly a month ago I raised [PR #124|
>>> https://github.com/jenkinsci/s3-plugin/pull/124] on the S3 plugin. It
>>> has not been reviewed or merged yet. I also noticed that there are quite a
>>> lot of open PRs and that the plugin hasn’t been released for more than a
>>> year and half.
>>>
>>> Possibly it is bad timing because of the holiday season. However if this
>>> is not the case, CloudBees would be more than happy to provide help and
>>> support with keeping the plugin up to date and secure. We would like to
>>> request co-maintainership for the plugin, unless there are active plans to
>>> make a new release of the plugin.
>>> CloudBees see the S3 Plugin as being a critical plugin for Jenkins users
>>> that want to run their builds on AWS.
>>>
>>> Best regards.
>>>
>> --
> 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/66ff5cef-6cc6-44d4-984b-06e432dcc801%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/CANWgJS4jqJ3f_dgJAQnCXD3oFjLkAsGB6nf1xEdMgv1RWsM53g%40mail.gmail.com.

Re: Happy Holiday

[Baptiste Mathus]

https://github.com/cdfoundation/foundation/issues/127

On Fri, Jan 10, 2020 at 1:58 PM Baptiste Mathus 
wrote:

> I think a strong concern as it is right now is that CDF's Slack is still
> on the free plan.
>
> I am going to ask around what are the plan and any ETA for this to be
> either approved, or rejected.
>
> I would not like us to work on the UX/UI refresh, but see older messages
> become inaccessible in a few weeks/months from now, preventing us from
> doing archeology to figure out some design/technical decisions after the
> fact or so.
>
>
>
> On Thu, Jan 9, 2020 at 5:32 PM Jesse Glick  wrote:
>
>> On Fri, Dec 27, 2019 at 7:34 AM Tim Jacomb  wrote:
>> > I’ve seen it work really well elsewhere, k8s has a very large slack
>> community with multiple sigs and user groups.
>>
>> Yes, and it works well in my experience. Jenkins X uses that
>> workspace, for example, and it was easy to sign up. +1 for using
>> Slack, strong -1 for IRC.
>>
>> --
>> 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/CANfRfr2-vEPFKLRrAuU31QjrEuyNKeZvbvHM8yTMU8R6SCYPZQ%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/CAPyTVp12RhDv-p2R%2B27jLxEh4PeZ6FEWMrQyucJorM53xAKxmw%40mail.gmail.com.

Re: Happy Holiday

[Baptiste Mathus]

I think a strong concern as it is right now is that CDF's Slack is still on
the free plan.

I am going to ask around what are the plan and any ETA for this to be
either approved, or rejected.

I would not like us to work on the UX/UI refresh, but see older messages
become inaccessible in a few weeks/months from now, preventing us from
doing archeology to figure out some design/technical decisions after the
fact or so.



On Thu, Jan 9, 2020 at 5:32 PM Jesse Glick  wrote:

> On Fri, Dec 27, 2019 at 7:34 AM Tim Jacomb  wrote:
> > I’ve seen it work really well elsewhere, k8s has a very large slack
> community with multiple sigs and user groups.
>
> Yes, and it works well in my experience. Jenkins X uses that
> workspace, for example, and it was easy to sign up. +1 for using
> Slack, strong -1 for IRC.
>
> --
> 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/CANfRfr2-vEPFKLRrAuU31QjrEuyNKeZvbvHM8yTMU8R6SCYPZQ%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/CAPyTVp0ar_8GjmX%3DtAMtGBZ9CKuG93z%3Dsyr9p_4a5Pfk9AW%3Dng%40mail.gmail.com.

Re: Is there ant API/way to make a plugin that runs some action periodically?

[Baptiste Mathus]

On Wed, Jan 8, 2020 at 5:59 PM Daniel Anechitoaie 
wrote:

> Awesome. So there are two options, this one with AsyncPeriodicWorker and
> the one from @Jeff where you can run it after each job.
> I'll look into seeing which one fits best for the current use case.
>

Possibly both, depending on what you want to achieve.

RunListener is the way to get results of builds in a live way. So you may
use it to gather stats on failure rates, etc.
Then, if you do not want to send things progressively, but batch them,
you'd store these results in some intermediate structure.

Then, if willing to send these results somewhere on a regular basis, you
would implement an AsyncPeriodicWork to do it.

HTH


> Thank you.
>
>
> On Wednesday, January 8, 2020 at 6:54:50 PM UTC+2, Jesse Glick wrote:
>>
>> On Wed, Jan 8, 2020 at 10:37 AM Daniel Anechitoaie
>>  wrote:
>> > Some Jenkins Java API that would allow me to run some code in the
>> background every day or so.
>>
>> https://javadoc.jenkins.io/hudson/model/AsyncPeriodicWork.html
>>
> --
> 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/783b22ad-ed65-4021-bdd1-0d497b3cd703%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/CAPyTVp1oW%3DAp7Tpg793XZNJNQWQnCrPv-7vU339-_FbtzY2o9A%40mail.gmail.com.

Re: Newest base pom with really old plugin

[Baptiste Mathus]

Bump bump bump, yes.

Yes, AFAIR for the Symbol annotation, but in some cases you may depend on
recent versions of plugins.

_Anyway_ then, the build will automatically fail if any plugin version
necessitate a more recent of the Core.
In such case, I would strongly recommend you simply bump to the request
recent version instead of playing around and fighting plugin version
compatibility.
Life is too short to keep plugins on very old Jenkins versions IMO. Even
2.60.x is quite old now (August 2017 already)
Anyway again, many times we have discussed that companies averse to
updating Jenkins Core also are very likely averse to upgrading plugin
themselves...

Many of us have done plugin parent pom updates a few times, so do not
hesitate to ask for help/review as needed Gavin.

Hope this helps.


On Thu, Dec 19, 2019 at 10:32 AM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Awesome, 2.60 builds though tests fail in good ways I need to fix
>
> Can 2.60 support pipeline symbols? I'm thinking I might want to expand it
> a bit so you can trigger browser notifications inside of pipelines.
>
> Gavin
>
>
> On Thu, Dec 19, 2019 at 1:26 AM Mark Waite 
> wrote:
>
>> I think you'll have better results if you switch to java 8 and Jenkins
>> 2.60 or newer as base version. That is the first LTS that required Java 8,
>> if I recall correctly.
>>
>> Switch the major version of the plugin at release and call it good.
>>
>> On Thu, Dec 19, 2019, 2:17 AM 'Gavin Mogan' via Jenkins Developers <
>> jenkinsci-dev@googlegroups.com> wrote:
>>
>>> Hey all,
>>>
>>> I wanted to do some cleanup, do a few fixes, and release a new version
>>> of a really old plugin of mine, so I could move the docs from wiki to
>>> github.
>>>
>>> I thought it would be a good idea to update to latest base pom cause ...
>>> its better.
>>>
>>> So it was originally targeting 1.455 with java 5 (which i now think
>>> should have been 7). Updating it to use 7, I still fail to build due to
>>> enforcer errors
>>>
>>> [INFO] Restricted to JDK 1.7 yet org.codehaus.
>>> *mojo:animal-sniffer-annotations:jar:1.18:provided* contains
>>> org/codehaus/mojo/animal_sniffer/IgnoreJRERequirement.class targeted to JDK
>>> 8
>>> [WARNING] Rule 2:
>>> org.apache.maven.plugins.enforcer.EnforceBytecodeVersion failed with
>>> message:
>>> Found Banned Dependency:
>>> org.codehaus.mojo:animal-sniffer-annotations:jar:1.18
>>>
>>> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.BannedDependencies
>>> failed with message:
>>> Found Banned Dependency:* org.sonatype.sisu:sisu-guice:jar:3.1.0*
>>>
>>>
>>> Both of these come from the super early jenkins core. Is there a way to
>>> ignore this, or a good recommended core version to use? or can I just bump
>>> things?
>>>
>>> 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_Dutr1LxFDugY1vKwGCE_m5chB60QU1oeWgwVr4byFmx4bA%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/CAO49JtEjjSWuXnYOZS0HUdDDVm79sZXqN0DpVRDKgFUhNLz%3DPQ%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_DutxUTtdP-G36ug9jQy3yD6scw7BhqgYZjLdK%2B1TY6kgoQ%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/CAPyTVp3HhPiFvCXWpV%3DnXchp-uZQ43BSFe0MhnmiAwMH_W%2BqDQ%40mail.gmail.com.

Re: Jenkins 2.204.1 LTS RC testing started

[Baptiste Mathus]

Nope, Mark, don't be sorry, THANK YOU.

Better safe than sorry, and you're clearly doing a great job actually
checking the RCs.

On Mon, Dec 16, 2019 at 9:51 AM Mark Waite 
wrote:

> Special thanks to Oleg Nenashev for detecting my mistake.  The issues I
> was seeing were caused by *my mistakes* and are not related to anything
> specific to 2.204.1-rc.
>
> I made a merge error in the definition of a Blue Ocean organization folder
> and deleted an opening tag in the 'scm' section of a pipeline library
> definition.  Once that merge error was reverted, the job loads correctly
> and completely in Jenkins 2.204.1-rc.
>
> The on-disc copy I was using at run-time was different from the copy
> stored in source control.  Once they were made the same, then Jenkins
> 2.190.3 showed the same failure.
>
> The second mistake I made was that I had omitted a JCasC agent definition
> for one of my Windows agents and was mistakenly using an on-disk copy of
> the agent definition.  The on-disk copy was damaged in some way.  Once I
> defined the agent in JCasC, the agent ran correctly with Jenkins 2.204.1-rc.
>
> Sorry for the false alarms on both items!
>
> Mark Waite
>
> On Saturday, December 14, 2019 at 10:52:38 PM UTC-7, Mark Waite wrote:
>>
>> I've reported https://issues.jenkins-ci.org/browse/JENKINS-60484 against
>> 2.204.1-rc as a regression that needs more investigation.  An organization
>> folder job from Blue Ocean which parsed correctly with Jenkins 2.190.3 no
>> longer parses correctly with Jenkins 2.204.1-rc.
>>
>> I've also seen another XML parsing issue with the definition of one of my
>> windows agents being unusable while other windows (and non-windows) agent
>> definitions are read and processed correctly.
>>
>> I'll report more tomorrow or Monday.
>>
>> Mark Waite
>>
>> On Thursday, December 5, 2019 at 7:57:45 AM UTC-7, ogondza wrote:
>>>
>>> Hello everyone,
>>>
>>> Latest LTS RC was made public and it is ready to be tested. Final
>>> release is scheduled for 2019-12-18.
>>>
>>> Please, report your findings in this thread.
>>>
>>> Download bits from
>>> http://mirrors.jenkins-ci.org/war-stable-rc/2.204.1/jenkins.war
>>>
>>> Thanks!
>>> --
>>> oliver
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/abc69182-b268-4bd3-8ded-f6af35fef68e%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/CAPyTVp09hc1%2BYybHwsfoXWxAx%2BmCAJVVp-pR7JWwApkCHMWaxA%40mail.gmail.com.

Re: Proposal: Official Docker Image maintenance team (Jenkins and Agents)

[Baptiste Mathus]

I think it's actually quite useful when pinging people? Also when reading
such mentions on PRs and the likes, we immediately know it's a team. Also a
bit useful for auto-completion easiness I believe.

I will not fight for this though :). Either way is still ok for me.

My 2 cents

Le ven. 13 déc. 2019 à 19:19, Oleg Nenashev  a
écrit :

> The reason of the "team-" suffix was to follow the same convention as for
> SIGs in JEP-4 (sig-...). But I have no strong opinion, happy to remove it
>
> On Fri, Dec 13, 2019, 10:38 Ivan Fernandez Calvo 
> wrote:
>
>> I'd like to be involved also at least on the testing part
>>
>> El martes, 10 de diciembre de 2019, 12:34:05 (UTC+1), Oleg Nenashev
>> escribió:
>>>
>>> BTW, I suggest the following list of maintainers based on the recent
>>> activity:
>>>
>>>    - Mark Waite
>>>- Alex Earl
>>>- Carlos Sanchez
>>>- Oleg Nenashev
>>>- Baptiste Mathus
>>>- Olivier Vernin
>>>
>>> Alternative is to just keep all members of
>>> https://github.com/orgs/jenkinsci/teams/docker/members though some
>>> contributors are not active at the moment
>>>
>>> BR, Oleg
>>>
>>> On Tuesday, December 10, 2019 at 11:42:49 AM UTC+1, Mark Waite wrote:
>>>>
>>>> I would like that very much
>>>>
>>>> On Tue, Dec 10, 2019, 11:19 AM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Right now we have a number of official packages for Docker:
>>>>>
>>>>>- https://github.com/jenkinsci/docker
>>>>>- https://github.com/jenkinsci/docker-slave
>>>>>- https://github.com/jenkinsci/docker-ssh-slave
>>>>>- https://github.com/jenkinsci/docker-jnlp-slave
>>>>>- https://github.com/jenkinsci/jnlp-agents
>>>>>
>>>>> All these repositories have different teams which define permissions/.
>>>>> In addition to that we have jenkinsci/docker and
>>>>> jenkinsci/docker-packaging-team team which also grant permissions. It is
>>>>> quite difficult to manage the repositories in the current state, and it is
>>>>> difficult to request reviews.
>>>>>
>>>>> I suggest to keep things simple and just proceed with a single team
>>>>> for the official packaging:
>>>>>
>>>>>- Introduce an official "docker-packaging-team" under umbrella of
>>>>>Platform Special Interest group which currently manages Docker 
>>>>> packaging
>>>>>- Cleanup existing teams, leave just one for all official Jenkins
>>>>>master and agent mages. Plugin Docker packaging (e.g. Remoting over 
>>>>> Apache
>>>>>Kafka, Swarm plugin) will not be affected
>>>>>- Update GitHub and DockerHub teams to reflect the changes (mostly
>>>>>jenkins4eval which grants write permissions)
>>>>>- Add new team to CODEOWNERS in all repos
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Thanks in advance,
>>>>> Oleg
>>>>>
>>>>> --
>>>>> 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/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCPBvAvsqC4nqpr2e%2BqBOo2BdMqa%3DY5%3Dx%2BhVO735YzX_w%40mail.gmail.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/DR9nZMRgyu8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/a2eb969d-f874-47a0-9fcc-51ed874f2128%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/a2eb969d-f874-47a0-9fcc-51ed874f2128%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CAPfivLA-NJzBxVC3MMa95EcRCxDC0HUtZW93x89WsDR10Q9CJw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA-NJzBxVC3MMa95EcRCxDC0HUtZW93x89WsDR10Q9CJw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAPyTVp2vF8But_A%3DN8pJ09rRi4CLzcRoopdTd4%2B_yOS_83JbVg%40mail.gmail.com.

Re: Adopt a plugin request

[Baptiste Mathus]

Please also add existing/current maintainers in CC, we'll need either
her/his/their approvals, or wait 14 days usual timeout.
Cf. https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

On Fri, Dec 13, 2019 at 10:37 AM Terry Moreland 
wrote:

> I'm requesting to be made maintainer for the AppSpider Jenkinsci plugin
> using either of the following git accounts.
>
> 
> 
> jenkinsci:  https://plugins.jenkins.io/jenkinsci-appspider-plugin
> github:  https://github.com/rapid7/jenkinsci-appspider-plugin
> pull request: https://github.com/rapid7/jenkinsci-appspider-plugin/pull/5
> github id: either my work account (preferred): tmoreland-r7 or personal
> account: tsmoreland
> jenkins id: tmoreland
>
> inclusion of both accounts is because my personal account is associated
> with this e-mail address which could join the group while my work account
> is restricted from joining google groups
>
> In case it makes any difference the current maintainer's e-mail address is
> currently being redirected to my work account (terry_morel...@rapid7.com),
> I cannot gain control of his github account due as it's using two-factor
> authentication.  Nonico Bugash is no longer with Rapid7 which is why I'm
> seeking to become maintainer
>
> Terry Moreland
> terry.s.morel...@gmail.com
> terry_morel...@rapid7.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/CAM5UBjf7mg5vquc2tN6juhAOANrr5cSPeL6f3UpVGDzkpXnjvQ%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/CAPyTVp0wiDYZX1vFtpXL21d4FUisv7BDi5M%2BbY7cAw3MMC_JKw%40mail.gmail.com.

Re: Proposal: New twitter contributors

[Baptiste Mathus]

+2, I mean. So very yey ;)

Le mer. 11 déc. 2019 à 17:38, Kohsuke Kawaguchi  a écrit :

> Yay, +1
>
> On Wed, Dec 11, 2019 at 8:35 AM Tracy Miranda 
> wrote:
>
>> Hi all,
>>
>> As per the process outlined in JEP 10
>> , I would like to
>> propose two new Twitter Contributors for the @jenkinsci account.
>>
>> 1. Oleg Nenashev - Oleg has been regularly proposing tweets/retweets via
>> the Advocacy gitter channel as well as tweeting community highlights around
>> hacktoberfest, gsoc, SIGs, elections etc. For example
>> https://twitter.com/oleg_nenashev/status/1202631389277032449
>> https://twitter.com/oleg_nenashev/status/1194982086521872384
>> https://twitter.com/oleg_nenashev/status/1176981880786313217
>>
>> 2. Mark Waite - Mark regularly tweets around Platform SIG & Documentation
>> SIG, Jenkins git plugin, Jenkins online meetups and other community
>> highlights. For example:
>> https://twitter.com/MarkEWaite/status/1190616140868808705
>> https://twitter.com/MarkEWaite/status/1180093593073045504
>> https://twitter.com/MarkEWaite/status/1192437176446812160
>>
>> By giving Oleg & Mark access to schedule tweets, etc it will help the
>> community with more timely and regular communication around the many
>> community activities and technical developments.
>>
>> Please go ahead and vote/comment on this proposal. I will also add to an
>> upcoming board meeting for approval there.
>>
>> Regards,
>> Tracy
>>
>>
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6qfPKYm_5O4bW-%2Bnxhu2y6u-rf4C1eH7meTA2h2taXY-A%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Kohsuke Kawaguchi
>
> --
> 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/CAN4CQ4xQQpfR_d2U3FPSNs3y_2nHX-4iZuFFT%3Dkc6DZq3mMrEg%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/CANWgJS5MLLKKWcyxc0LmKdsBe4y%2BBFKdbnnEKLGaxs66P-J2Ng%40mail.gmail.com.

Re: Offical policy for plugins stored not in organization

[Baptiste Mathus]

Actually, it is not allowed Mark, as summarized by Daniel in
https://github.com/jenkins-infra/repository-permissions-updater/pull/41#issuecomment-249007272
As Daniel wrote, I had done some history excavation a few years ago to
understand also what had been the historical expectations.
And it had been confirmed that the expectation always was to host under the
Jenkins org.

We have started requiring it more clearly since 2 or 3+ years for various
reasons.
So, for any new plugin hosted in the last ~3 years (Slide has been doing an
awesome job on this BTW), I think it would be quite disingenuous to pretend
to be unaware that the expectation is to host under the jenkinsci GH org.
Now, during the hosting process, we even post at the end "Please remove
your original repository so that the jenkinsci repository is the definitive
source for the code. Also, please make sure you have a wiki page set up
with the following guidelines in mind".  (random example: HOSTING-863
)

In the very case of this octopus-deploy plugin, this was hosted before the
HOSTING project was put in place.
It was hosted by Oleg in
https://groups.google.com/d/msg/jenkinsci-dev/sFsi9qBEwa0/O9bA3l2naqsJ, and
Oleg made it clear it got forked, etc.
So I think similarly it would sound disingenuous to pretend that not using
https://github.com/jenkinsci/octopusdeploy-plugin but another one outside
the jenkinsci org would be perfectly normal :).

-- Baptiste


On Thu, Dec 5, 2019 at 9:31 AM Mark Waite  wrote:

> No, it is allowed to host a plugin outside the jenkinsci organization.
>
> On Thu, Dec 5, 2019, 1:31 AM 'Gavin Mogan' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> wrote:
>
>> So just saw octopus deploy was recently updated, and that it mentioned
>> docs were in the github repo
>>
>> Realized the plugin is being deployed from
>> https://github.com/OctopusDeploy/octopus-jenkins-plugin not
>> https://github.com/jenkinsci/octopusdeploy-plugin
>>
>> Is this something that update center should be preventing?
>>
>> 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_DutMUH6ApfjQ155AzKRN9PURO2kVkKywCv4vGGMquOBqEA%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/CAO49JtHMf69xoKSx6Featd41_4_2uxn86wqg5aGmu9_UAMH4zQ%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/CAPyTVp0v%3DEfn9U19sSJ-UHH%3DJG%2BskEt0-cSyg_rQ4VJ8GSmDRg%40mail.gmail.com.

Re: Backporting for LTS 2.204.1 started

[Baptiste Mathus]

Ack, thanks.

On Thu, Dec 5, 2019 at 9:45 AM ogondza  wrote:

> Thanks Baptiste. But as you said, this will be postponed to .2.
>
> On Tuesday, December 3, 2019 at 3:36:09 PM UTC+1, Baptiste Mathus wrote:
>>
>> Just as heads-up, also because I am not fully sure of the usual
>> practice/process: but I think this is worth mentioning:
>> https://issues.jenkins-ci.org/browse/JENKINS-57304 fix was just merged,
>> hence should land in next weekly next Monday or so.
>>
>> If possible to consider, I think this could be a good candidate maybe.
>> The fix is a one-liner.
>>
>> I would fully understand we'll wait for .2 for this one to receive more
>> weekly testing to be eligible for an LTS backport.
>> I just thought I'd mention it given it will not show up in the filter
>> before next week when it's finally marked as Resolved and released.
>>
>> Cheers
>>
>> Le lun. 25 nov. 2019 à 22:27, Oleg Nenashev  a
>> écrit :
>>
>>> I went through 2.205 and 2.206 changes and marked JIRA issues which may
>>> deserve backporting.
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Friday, November 22, 2019 at 9:18:16 AM UTC+1, ogondza wrote:
>>>>
>>>> Backporting has started and the RC is scheduled for 2019-12-04.
>>>>
>>>> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
>>>> Fixed:
>>>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.204.1-fixed
>>>> Rejected:
>>>>
>>>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.204.1-rejected
>>>> --
>>>> 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/a6a15fb4-defb-4475-a045-ecaa69de8270%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/a6a15fb4-defb-4475-a045-ecaa69de8270%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/f59e383f-9d2f-4d78-ad3a-3c24f3b113cf%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/f59e383f-9d2f-4d78-ad3a-3c24f3b113cf%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAPyTVp1vS-Q7Pk05uGaWV%3DtwiVcgLYX%2Bg8MnzyVnEHBnom7DTQ%40mail.gmail.com.

Re: Access to git parameter plugin

[Baptiste Mathus]

Hello,

Please also CC the current maintainer(s), as documented on
https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/

Thanks for stepping up!

On Wed, Dec 4, 2019 at 7:44 AM Raihaan Shouhell 
wrote:

> Hi All,
>
> I'd like to request access to the git parameter plugin.
> https://github.com/jenkinsci/git-parameter-plugin
>
> It seems to have been abandoned. I've tried reaching out to its current
> listed maintainers,
> https://github.com/jenkinsci/git-parameter-plugin/blob/f1daa529bef163c9b678b537b1d4ff98c2bbc39e/pom.xml#L39-L48
>
> One of whom, Niklaus has mentioned that he stepped down as maintainer in
> 2015 and Boguslaw(kilmas7) is the current maintainer. I have yet to receive
> any reply from him.
>
> I'd like to merge some of the PRs, move its docs to github, enable
> dependabot and incrementals and cut a new release.
>
> Github username: res0nance
> Jenkins infra account: raihaan
>
> 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/1dea1ad2-b86f-4a05-b2ed-d6e5510caf5e%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/CAPyTVp3ZuCc%2B5N6Tiwq%2BCgwF9FEvpKPCAQo%2BKAFccys6DJuN-A%40mail.gmail.com.

Re: Backporting for LTS 2.204.1 started

[Baptiste Mathus]

Just as heads-up, also because I am not fully sure of the usual
practice/process: but I think this is worth mentioning:
https://issues.jenkins-ci.org/browse/JENKINS-57304 fix was just merged,
hence should land in next weekly next Monday or so.

If possible to consider, I think this could be a good candidate maybe. The
fix is a one-liner.

I would fully understand we'll wait for .2 for this one to receive more
weekly testing to be eligible for an LTS backport.
I just thought I'd mention it given it will not show up in the filter
before next week when it's finally marked as Resolved and released.

Cheers

Le lun. 25 nov. 2019 à 22:27, Oleg Nenashev  a
écrit :

> I went through 2.205 and 2.206 changes and marked JIRA issues which may
> deserve backporting.
>
> Best regards,
> Oleg
>
>
> On Friday, November 22, 2019 at 9:18:16 AM UTC+1, ogondza wrote:
>>
>> Backporting has started and the RC is scheduled for 2019-12-04.
>>
>> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
>> Fixed:
>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.204.1-fixed
>> Rejected:
>> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.204.1-rejected
>> --
>> oliver
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a6a15fb4-defb-4475-a045-ecaa69de8270%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/CANWgJS5R46ZS7dk65LKni1W5cEKm%3Do-TT6Cex5gSs6G-LCF%2Bxg%40mail.gmail.com.