Jenkins 2.303.3 LTS RC testing started

[raihaan...@gmail.com]

Hey all,

LTS RC is ready for testing. The final release will be on 3rd November

Please report any findings / issues in this thread

Download the RC 
here: 
https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.303.3-rc31394.c5beb283d2b9/jenkins-war-2.303.3-rc31394.c5beb283d2b9.war

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/a0404168-b1af-4a33-8ac8-039b228b3690n%40googlegroups.com.

Backporting for LTS 2.303.3 Started

[raihaan...@gmail.com]

Backporting has started and the RC is scheduled for 20th October

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146

Fixed: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.303.3-fixed

Rejected: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.303.3-rejected

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/eb9e7e1c-2d09-49bf-9fb6-1bf36aedbd36n%40googlegroups.com.

Re: Release team members

[raihaan...@gmail.com]

+1 I'd be happy to help where I can

On Monday, 27 September 2021 at 17:16:55 UTC+8 timja...@gmail.com wrote:

> Thanks all.
>
> I've added it to the people who have replied so far:
>
> [image: image.png]
>
> Cheers
> Tim
>
> On Mon, 27 Sept 2021 at 07:52, 'wfoll...@cloudbees.com' via Jenkins 
> Developers  wrote:
>
>> Good initiative Tim, thank you :) 
>>
>> (yes you can add me ^^)
>>
>> Wadeck
>>
>> On Friday, September 24, 2021 at 9:52:30 AM UTC+2 Ildefonso Montero wrote:
>>
>>> No issues from my side :-) Thanks for driving this Tim!
>>>
>>> On Thu, Sep 23, 2021 at 9:29 PM Mark Waite  wrote:
>>>
 I would like to be a member of that group.

 On Wed, Sep 22, 2021 at 11:49 PM Tim Jacomb  wrote:

> Hello
>
> Continuing from 
> https://groups.google.com/g/jenkinsci-dev/c/YhXRKybGgMg/m/IRjH_VykCwAJ
>  
>
> I would like to invite the previous release leads to join the release 
> team officially in jenkinsci/jenkins-infra GitHub organisations:
>
>
>- 
>
>Beatriz Muñoz (@bmunozm)
>- 
>
>Ildefonso Montero (@imonteroperez)
>- 
>
>Mark Waite (@MarkEWaite)
>- 
>
>Raihaan Shouhell (@res0nance)
>- 
>
>Basil Crow (@basil)
>
>
> Daniel, Olivier (olblak), Wadeck, Oleg you are all in the team in 
> jenkins-infra, would you like to join the team in jenkinsci as well?
>
> If you would like to join then please reply to this email.
>
> For others if you would like to get involved in a release then 
> consider stepping up for a release lead role for an LTS release or 
> joining 
> the #jenkins-release room on Libera IRC
>
> 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-3BieVaZAEP3wJBVzpKe1g5YvjEBcRag49vSJ-Fy8Q2%3DDQCw%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-de...@googlegroups.com.

>>> To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFtg4-tYwuqB%3DqnA0tvR4MDiL2j%3D_QhaFHtnC8%3DrCmHPQ%40mail.gmail.com
  
 
 .

>>>
>>>
>>> -- 
>>>
>>> Ildefonso Montero Pérez
>>> Senior Software Engineer
>>>
>>> CloudBees, Inc
>>>
>>>
>>>
>>> E: imon...@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-de...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/2bda6d62-3252-4bb7-97fc-29980ed32465n%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/ef8366d6-d4eb-41f2-a638-8505034e0390n%40googlegroups.com.

Re: ASM in core

[raihaan...@gmail.com]

In the case of system 
properties https://www.jenkins.io/doc/book/managing/system-properties/

Says:

Compatibility 


We do *NOT* guarantee that system properties will remain unchanged and 
functional indefinitely. These switches are often experimental in nature, 
and subject to change without notice. If you find these useful, please file 
a ticket to promote it to an official feature


So breaking it is not the worst.
On Tuesday, 15 June 2021 at 11:03:16 UTC+8 m...@basilcrow.com wrote:

> On Mon, Jun 14, 2021 at 7:36 PM Jesse Glick  wrote:
> >
> > JNR may be a similar story. I see all of two usages in core—both 
> disabled unless you set a system property. Just deleting it all may be 
> easier
>
> I had already noticed that as well and thought about opening such a PR
> to delete all usages of JNR. I decided to settle for removing
> `jna-posix` first. :-) But regarding removing JNR, what if someone is
> relying on that system property? Unlike API changes, where I can
> easily check `usage-in-plugins` to see how many plugins (both open
> source and CloudBees-proprietary) are still using a given API, there
> is no equivalent for me to check how many installations are relying on
> a given system property being said. This makes me a bit nervous to
> remove it. How has the Jenkins project handled cases like this
> historically?
>
> I can give one example of how I handled a similar situation in Email
> Extension. In 2.78 [1] (October 2020) I announced in the release notes
> that "integration with the Static Analysis Utilities plugin has been
> deprecated in the Email Extension plugin and will be removed in a
> future release", linking to the relevant Jira issue. In 2.81 [2]
> (January 2021) I again announced in the release notes (more strongly
> this time) that "integration with the Static Analysis Utilities plugin
> was deprecated in 2.78 and is scheduled to be removed in the first
> quarter of 2021", again linking to the relevant Jira issue. In 2.82
> [3] (March 2021), I pulled the plug and announced in the release notes
> that "as of 2.82, integration with the Static Analysis Utilities
> plugin has been removed from the Email Extension plugin".
>
> I gave users a chance to speak up. Nobody spoke up. I gave users a
> second chance to speak up. Nobody spoke up. I pulled the plug. Nobody
> complained. I think it went pretty well.
>
> Perhaps this might be a pattern worth following in Jenkins core?
>
> [1] 
> https://github.com/jenkinsci/email-ext-plugin/releases/tag/email-ext-2.78
> [2] 
> https://github.com/jenkinsci/email-ext-plugin/releases/tag/email-ext-2.81
> [3] 
> https://github.com/jenkinsci/email-ext-plugin/releases/tag/email-ext-2.82
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/decb52d8-ca98-4e73-8945-6014a5d9c2c0n%40googlegroups.com.

LTS 2.289.1 RC

[raihaan...@gmail.com]

Hey everyone,

The RC is available:

https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/2.289.1-SNAPSHOT/jenkins-war-2.289.1-20210519.141720-1.war

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/86928e42-6eae-4357-b645-6b186302664fn%40googlegroups.com.

Backporting has started and the RC is scheduled for 19th May

[raihaan...@gmail.com]

Candidates: https://issues.jenkins-ci.org/issues/?filter=12146

Fixed: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.289.1-fixed

Rejected: 
https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.289.1-rejected

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/7e1874d7-7435-4516-ab73-bb80648677b9n%40googlegroups.com.

Re: Looking for release lead for 2.289.1

[raihaan...@gmail.com]

Hey Tim,

Sure I think I'll be able to find the time to do it. 
As long as my timezone(GMT+8) is not a blocker for anything.

Cheers,
Raihaan

On Saturday, 8 May 2021 at 06:04:42 UTC+8 Oleg Nenashev wrote:

> If there are no other volunteers, I will find time to coordinate the 
> release if it is not a security one.
> But it would be really great if somebody else steps up. Maybe James Nord, 
> Raihaan, Basil or Ramon would be interested.
>
>
> On Friday, May 7, 2021 at 10:32:49 AM UTC+2 timja...@gmail.com wrote:
>
>> Hello
>>
>> Is anyone interested in being the release lead for 2.289.1?
>>
>> Planned dates can be seen on the event calendar: 
>> https://www.jenkins.io/events/#event-calendar
>> Release candidate by 19th May
>> Release on 2nd June
>>
>> The documentation is at:
>>
>> https://github.com/jenkins-infra/release/blob/master/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md
>>
>> I've initialised the release branches already so you won't need direct 
>> merge access anywhere, you will be able to do any pull requests from forks
>>
>> I'll be available to answer any questions and provide guidance (along 
>> with hopefully other past release leads)
>>
>> We chat in #jenkins-release on freenode IRC, 
>> https://www.jenkins.io/chat/#jenkins-release
>>
>> Anyone interested?
>>
>> 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/40ab2cad-6fbc-41a0-8f79-c836f3f4ecf9n%40googlegroups.com.

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

[raihaan...@gmail.com]

We should have an EOL policy as it stands we make breaking changes to 
Jenkins where plugins that have not been released recently are effectively 
disregarded.
We need to set a clear line where we believe its ok to break a plugin which 
can perhaps be part of this EOL policy.

For an EOLed plugin we could use a similar approach to plugin adoption. 
Where the maintainer has the option of now fixing up the possible problems 
with the plugin and release a new version. Which would reset its EOL 
countdown.

Cheers,
Raihaan
On Tuesday, 27 April 2021 at 15:29:46 UTC+8 bma...@gmail.com wrote:

> 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 

Re: Proposal: Disabling FLoC in Jenkins and the Jenkins websites

[raihaan...@gmail.com]

Hey Oleg,

I think this is a great suggestion.

The privacy category idea is also interesting is there any other 
interesting settings we could offer users there?

Cheers,
Raihaan

On Wednesday, 28 April 2021 at 16:59:41 UTC+8 Oleg Nenashev wrote:

> Hi all,
>
> As you may have heard, Google is rolling out its FLoC (Federated Learning 
> of Cohorts) tracking system, for advertisement needs. This system is 
> enabled in Google Chrome by default, and it is a corporate standard for 
> many of the Jenkins users. They cannot easily opt out. Yesterday GitHub set 
> a good precedent by disabling FLoC by default 
> .
>  
> I think we should do the same.
>
> We can explicitly disable FLoC on Jenkins resources by setting the 
> *Permissions-Policy:* *interest-cohort=() *header in Jenkins 
> distributions by default and on our websites: jenkins.io, 
> plugins.jenkins.io, javadoc, update center, etc., etc..
>
> *Jenkins distributions.* For the Jenkins core, it is a small patch adding 
> additional headers (e.g. here 
> ).
>  
> Probably we should introduce the new "Privacy" category in the "Manage 
> Security" screen for better UX, but this particular control should be also 
> manageable by system properties so that the settings always apply.
>
> *Jenkins Infa.*  For our infra, It should be easy to do for resources 
> we host in the main infra Kubernetes cluster. Although in some cases it may 
> prevent Jenkins-friendly (or not) advertisements from popping up for users, 
> I think we should rather put privacy first and disable FLoC on our 
> resources. Google Analytics might also be a subject for removal, but I 
> suggest to have a separate thread about it
>
> What do you think?
>
> References:
>
>- https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea
>- 
>
> https://github.blog/changelog/2021-04-27-github-pages-permissions-policy-interest-cohort-header-added-to-all-pages-sites/
>
> 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/997bab4e-f05f-4cac-b007-a25b90c7f77dn%40googlegroups.com.

Re: Unforking Commons FileUpload

[raihaan...@gmail.com]

Turns out dependabot seems to want the unforking
https://github.com/jenkinsci/jenkins/pull/5171

The comment regarding DiskFileItem in FileParameterValue dates back 13 
years.
Regarding JEP-200 there might be some rogue plugin that perhaps attempts to 
serialize this apparently unserializable object.
Perhaps we should remove it from the whitelist and test it. Even 
FileParameterValue uses fileitem transiently so no serialization happens 
there.


On Wednesday, 13 January 2021 at 13:09:01 UTC+8 m...@basilcrow.com wrote:

> On Tue, Jan 12, 2021 at 7:33 PM Jesse Glick  wrote:
> >
> > sounds like it would break normal usage from Jenkins
>
> The status quo is Commons FileUpload 1.3.1-jenkins-2 (patch in my
> previous message), which _already_ removed serialization from
> DiskFileItem.
>
> Here is the timeline of events upstream:
>
> Feb 7, 2014: Commons FileUpload 1.3.1 released [1]
>
> May 26, 2016: Commons FileUpload 1.3.2 released [2], in which
> CVE-2016-3092 is fixed (see
> src/main/java/org/apache/commons/fileupload/MultipartStream.java)
>
> July 3, 2020: Commons FileUpload 1.4.0 released [3], in which
> DiskFileItem is made no longer Serializable (see
> src/main/java/org/apache/commons/fileupload/FileItem.java)
>
> Meanwhile, in Jenkins-land:
>
> Sep 27, 2014: Jenkins adopts 1.3.1-jenkins-1 [4] in commit 28d997704f,
> in which DiskFileItem is made no longer Serializable, preceding upstream
> by over 6 years (see
> src/main/java/org/apache/commons/fileupload/FileItem.java)
>
> Sep 28-29, 2017: Jenkins adopts 1.3.1-jenkins-2 [5] in commit
> ea981a029c, in which CVE-2016-3092 is fixed, a year and a half after
> upstream (see
> src/main/java/org/apache/commons/fileupload/MultipartStream.java)
>
> Both of the patches from the Jenkins fork are present in upstream
> release 1.4, so we should be able to unfork to upstream release 1.4.
>
> Can you see a flaw in my reasoning?
>
> [1] 
> https://archive.apache.org/dist/commons/fileupload/source/commons-fileupload-1.3.1-src.tar.gz
> [2] 
> https://archive.apache.org/dist/commons/fileupload/source/commons-fileupload-1.3.2-src.tar.gz
> [3] 
> https://archive.apache.org/dist/commons/fileupload/source/commons-fileupload-1.4-src.tar.gz
> [4] 
> https://repo.jenkins-ci.org/releases/commons-fileupload/commons-fileupload/1.3.1-jenkins-1/commons-fileupload-1.3.1-jenkins-1-src.tar.gz
> [5] 
> https://repo.jenkins-ci.org/releases/commons-fileupload/commons-fileupload/1.3.1-jenkins-2/commons-fileupload-1.3.1-jenkins-2-source-release.zip
>

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