Re: LTS backporting policy

[jn...@cloudbees.com]

https://github.com/jenkins-infra/jenkins.io/pull/4547#pullrequestreview-747378748

On Monday, September 6, 2021 at 6:25:41 PM UTC+1 jn...@cloudbees.com wrote:

> >  This is already covered as far as I can tell:
>
> I think Tim was referring to the "subject to risk" rather than "not a bug".
>
> As I read
>Any user can propose that a bug fix be backported to LTS by labeling 
> with lts-candidate 
> .
>  
>
>
> especially in the combination with "Backporters use this query 
>  to list up issues that 
> need to be attended once resolved."  where the query is "issuetype in (Bug, 
> Improvement)" I am not sure that covers library updates for reasons other 
> than bugs (and improvements - but funnily that is at odds with the previous 
> "bug fix" and non bug fixes have been historically denied).
>
>
> What I am hearing at least is that no body is against this in principal so 
> I will try and come up with a PR to https://www.jenkins.io/download/lts/ 
> that describes the situation and we can move the details of wording over 
> there.
>
> /James
>
> On Thursday, September 2, 2021 at 8:46:08 PM UTC+1 bma...@gmail.com wrote:
>
>> 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 

Re: LTS backporting policy

[jn...@cloudbees.com]

>  This is already covered as far as I can tell:

I think Tim was referring to the "subject to risk" rather than "not a bug".

As I read
   Any user can propose that a bug fix be backported to LTS by labeling 
with lts-candidate 
.
 


especially in the combination with "Backporters use this query 
 to list up issues that 
need to be attended once resolved."  where the query is "issuetype in (Bug, 
Improvement)" I am not sure that covers library updates for reasons other 
than bugs (and improvements - but funnily that is at odds with the previous 
"bug fix" and non bug fixes have been historically denied).


What I am hearing at least is that no body is against this in principal so 
I will try and come up with a PR to https://www.jenkins.io/download/lts/ 
that describes the situation and we can move the details of wording over 
there.

/James

On Thursday, September 2, 2021 at 8:46:08 PM UTC+1 bma...@gmail.com wrote:

> 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

Re: potential regression in master

[Basil Crow]

Already done in jnr/jnr-ffi#269 jenkinsci/jenkins#5712

On Mon, Sep 6, 2021 at 9:36 AM jn...@cloudbees.com 
wrote:

> You just beat me to it!
>
> creating the PRs.
>
> On Monday, September 6, 2021 at 5:28:34 PM UTC+1 m...@basilcrow.com wrote:
>
>> It's jenkinsci/jenkins#5703, which pulled in jnr/jnr-ffi#252, which
>> updated JUnit from 4 to 5 in jnr-ffi without putting the new JUnit 5
>> JAR in the test scope. That means the following JARs are now
>> (erroneously) bundled in the Jenkins WAR:
>>
>> [INFO] +- org.junit.jupiter:junit-jupiter-engine:jar:5.7.2:compile
>> [INFO] | +- org.apiguardian:apiguardian-api:jar:1.1.0:compile
>> [INFO] | +- org.junit.platform:junit-platform-engine:jar:1.7.2:compile
>> [INFO] | | +- org.opentest4j:opentest4j:jar:1.2.0:compile
>> [INFO] | | \- org.junit.platform:junit-platform-commons:jar:1.7.2:compile
>> [INFO] | \- org.junit.jupiter:junit-jupiter-api:jar:5.7.2:compile
>>
>> Needless to say, we don't want these in the WAR, and their mere
>> presence on the classpath exposes us to SUREFIRE-1911, so we should
>> exclude them and file an upstream issue to fix jnr/jnr-ffi#252 by
>> putting these dependency in test scope.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/760ce5a3-4f48-4828-83fd-23fd4230879bn%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/CAFwNDjqUDYjPKxWbMvO8iL2AyzPRFpc6n%3DC6sd8BW5Mt9ObxKA%40mail.gmail.com.

Re: potential regression in master

[jn...@cloudbees.com]

You just beat me to it!

creating the PRs.

On Monday, September 6, 2021 at 5:28:34 PM UTC+1 m...@basilcrow.com wrote:

> It's jenkinsci/jenkins#5703, which pulled in jnr/jnr-ffi#252, which
> updated JUnit from 4 to 5 in jnr-ffi without putting the new JUnit 5
> JAR in the test scope. That means the following JARs are now
> (erroneously) bundled in the Jenkins WAR:
>
> [INFO] +- org.junit.jupiter:junit-jupiter-engine:jar:5.7.2:compile
> [INFO] | +- org.apiguardian:apiguardian-api:jar:1.1.0:compile
> [INFO] | +- org.junit.platform:junit-platform-engine:jar:1.7.2:compile
> [INFO] | | +- org.opentest4j:opentest4j:jar:1.2.0:compile
> [INFO] | | \- org.junit.platform:junit-platform-commons:jar:1.7.2:compile
> [INFO] | \- org.junit.jupiter:junit-jupiter-api:jar:5.7.2:compile
>
> Needless to say, we don't want these in the WAR, and their mere
> presence on the classpath exposes us to SUREFIRE-1911, so we should
> exclude them and file an upstream issue to fix jnr/jnr-ffi#252 by
> putting these dependency in test scope.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/760ce5a3-4f48-4828-83fd-23fd4230879bn%40googlegroups.com.

Re: potential regression in master

[Basil Crow]

It's jenkinsci/jenkins#5703, which pulled in jnr/jnr-ffi#252, which
updated JUnit from 4 to 5 in jnr-ffi without putting the new JUnit 5
JAR in the test scope. That means the following JARs are now
(erroneously) bundled in the Jenkins WAR:

[INFO] +- org.junit.jupiter:junit-jupiter-engine:jar:5.7.2:compile
[INFO] |  +- org.apiguardian:apiguardian-api:jar:1.1.0:compile
[INFO] |  +- org.junit.platform:junit-platform-engine:jar:1.7.2:compile
[INFO] |  |  +- org.opentest4j:opentest4j:jar:1.2.0:compile
[INFO] |  |  \- org.junit.platform:junit-platform-commons:jar:1.7.2:compile
[INFO] |  \- org.junit.jupiter:junit-jupiter-api:jar:5.7.2:compile

Needless to say, we don't want these in the WAR, and their mere
presence on the classpath exposes us to SUREFIRE-1911, so we should
exclude them and file an upstream issue to fix jnr/jnr-ffi#252 by
putting these dependency in test scope.

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

Re: potential regression in master

[Mark Waite]

Thanks for investigating.  Weekly release is scheduled to run tomorrow.

On Mon, Sep 6, 2021 at 10:00 AM jn...@cloudbees.com 
wrote:

> Hi all,
>
> something is looking very fishy with the incrementals built recently.
>
> basically no tests run for plugins (at all)
>
> It is not that they do fail, but that maven executes zero tests.
>
> e.g.
> mvn -U clean test -s "c:\Users\jnord\.m2\settings_no_mirror.xml"
> -DfailIfNoTests -Djenkins.version=2.310-rc31475.ac421478662e
>
> fails (using bouncycastle-api as the plugin under test) and that
> incremental version is from
> https://ci.jenkins.io/job/Core/job/jenkins/job/master/2817/
>
> 2.309 is ok - I am bisecting to try and find the specific commit - but
> whomever is potentially creating the release today may want to hold of (or
> put the release job in disabled mode on trusted.ci).
>
> /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/03fe9627-21ab-46ba-9ea2-44f237e979b3n%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/CAO49JtF6ETVp1TQOexGw4F%3DT48iM3iG9vm%2Bj%3D0kBc3mNkmauhg%40mail.gmail.com.

potential regression in master

[jn...@cloudbees.com]

Hi all,

something is looking very fishy with the incrementals built recently.

basically no tests run for plugins (at all)

It is not that they do fail, but that maven executes zero tests.

e.g. 
mvn -U clean test -s "c:\Users\jnord\.m2\settings_no_mirror.xml" 
-DfailIfNoTests -Djenkins.version=2.310-rc31475.ac421478662e

fails (using bouncycastle-api as the plugin under test) and that 
incremental version is 
from https://ci.jenkins.io/job/Core/job/jenkins/job/master/2817/ 

2.309 is ok - I am bisecting to try and find the specific commit - but 
whomever is potentially creating the release today may want to hold of (or 
put the release job in disabled mode on trusted.ci).

/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/03fe9627-21ab-46ba-9ea2-44f237e979b3n%40googlegroups.com.

Re: Postponing 2.303.2 by two weeks

[Mark Waite]

+1 from me.

On Mon, Sep 6, 2021 at 5:48 AM Tim Jacomb  wrote:

> Sounds fine to me.
> If no negative feedback by end of tomorrow let’s adjust the dates
>
> On Mon, 6 Sep 2021 at 11:26, Raul Arabaolaza 
> wrote:
>
>> +1
>>
>> On Monday, September 6, 2021 at 12:24:24 PM UTC+2 Daniel Beck wrote:
>>
>>> Hi everyone,
>>>
>>> I'd like to postpone 2.303.2 by two weeks. RC would be scheduled for
>>> September 22, the final release on October 6. All future scheduled dates
>>> would be postponed accordingly.
>>>
>>> We've done this occasionally in the past when there are scheduling or
>>> availability issues, typically around Christmas, and sometimes during
>>> summer or JW/DW travels.
>>>
>>> In this case, I'd like to include security fixes in the release, and I'm
>>> not confident we'll be done on time with their preparation. The wiki infra
>>> issue[1] isn't helping either.
>>>
>>> Thoughts?
>>>
>>> Daniel
>>>
>>> 1: https://www.jenkins.io/blog/2021/09/04/wiki-attacked/
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/9747100e-ae34-46f7-a9ea-9b8a6dbe4060n%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/CAH-3BicNn2nY%3Dhc%3D8%3DPw_9VEX1KE1hVPsjyVLj9%2Bd0O047_QWA%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/CAO49JtEjov2YsUo5TDz7SWGx%2BbfFA0GGj8SkdWJyAv2ixL%2BxSg%40mail.gmail.com.

Re: Postponing 2.303.2 by two weeks

[Tim Jacomb]

Sounds fine to me.
If no negative feedback by end of tomorrow let’s adjust the dates

On Mon, 6 Sep 2021 at 11:26, Raul Arabaolaza 
wrote:

> +1
>
> On Monday, September 6, 2021 at 12:24:24 PM UTC+2 Daniel Beck wrote:
>
>> Hi everyone,
>>
>> I'd like to postpone 2.303.2 by two weeks. RC would be scheduled for
>> September 22, the final release on October 6. All future scheduled dates
>> would be postponed accordingly.
>>
>> We've done this occasionally in the past when there are scheduling or
>> availability issues, typically around Christmas, and sometimes during
>> summer or JW/DW travels.
>>
>> In this case, I'd like to include security fixes in the release, and I'm
>> not confident we'll be done on time with their preparation. The wiki infra
>> issue[1] isn't helping either.
>>
>> Thoughts?
>>
>> Daniel
>>
>> 1: https://www.jenkins.io/blog/2021/09/04/wiki-attacked/
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/9747100e-ae34-46f7-a9ea-9b8a6dbe4060n%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/CAH-3BicNn2nY%3Dhc%3D8%3DPw_9VEX1KE1hVPsjyVLj9%2Bd0O047_QWA%40mail.gmail.com.

Re: Postponing 2.303.2 by two weeks

[Raul Arabaolaza]

+1

On Monday, September 6, 2021 at 12:24:24 PM UTC+2 Daniel Beck wrote:

> Hi everyone,
>
> I'd like to postpone 2.303.2 by two weeks. RC would be scheduled for 
> September 22, the final release on October 6. All future scheduled dates 
> would be postponed accordingly.
>
> We've done this occasionally in the past when there are scheduling or 
> availability issues, typically around Christmas, and sometimes during 
> summer or JW/DW travels.
>
> In this case, I'd like to include security fixes in the release, and I'm 
> not confident we'll be done on time with their preparation. The wiki infra 
> issue[1] isn't helping either.
>
> Thoughts?
>
> Daniel
>
> 1: https://www.jenkins.io/blog/2021/09/04/wiki-attacked/
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9747100e-ae34-46f7-a9ea-9b8a6dbe4060n%40googlegroups.com.

Postponing 2.303.2 by two weeks

['Daniel Beck' via Jenkins Developers]

Hi everyone,

I'd like to postpone 2.303.2 by two weeks. RC would be scheduled for September 
22, the final release on October 6. All future scheduled dates would be 
postponed accordingly.

We've done this occasionally in the past when there are scheduling or 
availability issues, typically around Christmas, and sometimes during summer or 
JW/DW travels.

In this case, I'd like to include security fixes in the release, and I'm not 
confident we'll be done on time with their preparation. The wiki infra issue[1] 
isn't helping either.

Thoughts?

Daniel

1: https://www.jenkins.io/blog/2021/09/04/wiki-attacked/

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/48F1EF55-4858-4E3C-8884-364BEE93C795%40beckweb.net.

Re: 2.303.2 release lead

[Beatriz Munoz]

I would like to be! :-D

> El 6 sept 2021, a las 9:25, Tim Jacomb  escribió:
> 
> Hello
> 
> Is anyone interested in being the release lead for 2.303.2?
> 
> Planned dates can be seen on the event calendar: 
> https://www.jenkins.io/events/#event-calendar 
> 
> Release candidate by 8th September (apologies for short notice)
> Release on 22nd September
> 
> The documentation is at:
> https://github.com/jenkins-infra/release/blob/master/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md
>  
> 
> 
> 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/CAH-3Bidwce0ZN%3DmFdbOMpnismvsYYUAex0LpRSba_CU9xXs9KA%40mail.gmail.com
>  
> .

Beatriz Muñoz Manso
Sr Software Engineer 
CloudBees, Inc.



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

2.303.2 release lead

[Tim Jacomb]

Hello

Is anyone interested in being the release lead for 2.303.2?

Planned dates can be seen on the event calendar:
https://www.jenkins.io/events/#event-calendar
Release candidate by 8th September (apologies for short notice)
Release on 22nd September

The documentation is at:
https://github.com/jenkins-infra/release
/blob/master/.github/ISSUE_TEMPLATE/1-lts-release-checklist.md

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/CAH-3Bidwce0ZN%3DmFdbOMpnismvsYYUAex0LpRSba_CU9xXs9KA%40mail.gmail.com.