New LTS based on 2.107

94 views
Skip to first unread message

Oliver Gondža

unread,
Feb 15, 2018, 3:26:45 AM2/15/18
to jenkin...@googlegroups.com
As greed on Governance meeting, the next LTS line will be based on
latest weekly release. That means, there are no backports to be added
for .1 provided we do not discover something urgent that would cause us
to expedite some or reconsider our choice of baseline - which we do not
anticipate.

Therefore, I would like to encourage all the folks that kindly help us
test the RCs to use 2.107 weekly(!). Note formally we are still in a
backportig period and testing is planned to start in two weeks, though
with the bits already out, there is no reason not to start right away.

Cheers
--
oliver

Daniel Beck

unread,
Feb 22, 2018, 3:31:19 PM2/22/18
to jenkin...@googlegroups.com

> On 15. Feb 2018, at 09:26, Oliver Gondža <ogo...@gmail.com> wrote:
>
> As greed on Governance meeting, the next LTS line will be based on latest weekly release. That means, there are no backports to be added for .1 provided we do not discover something urgent that would cause us to expedite some or reconsider our choice of baseline - which we do not anticipate.
>
> Therefore, I would like to encourage all the folks that kindly help us test the RCs to use 2.107 weekly(!). Note formally we are still in a backportig period and testing is planned to start in two weeks, though with the bits already out, there is no reason not to start right away.

It's been a week. Any news from testing, or anything we've since learned about the current weeklies? I've seen some grumbling about the XML 1.1 change that went into 2.105, but mostly people downgrading and resolved by `sed -i`. Anything else we should know while we can still reconsider the baseline choice (or nominate backports)?

Daniel

Mark Waite

unread,
Feb 22, 2018, 11:27:28 PM2/22/18
to jenkin...@googlegroups.com
I've been running 2.107 since last week and have found no surprises in my tests.

I'm running a Docker instance with permanent agents connected from CentOS 6, CentOS 7, Debian 8, Debian 9, Ubuntu 14, Ubuntu 16, Windows 7, and Windows 10.

My configuration is mostly focused on detecting problems in the git plugin and the git client plugin.  The setup includes multi-branch pipeline jobs that monitor the git plugin and git client plugin, other multi-branch jobs that monitor my jenkins-bugs repository and a private version of the same repository, and many jobs which check for specific bugs.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9479AADB-C26C-4C1D-B287-EA2A7DB1C583%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Oleg Nenashev

unread,
Feb 23, 2018, 11:16:20 AM2/23/18
to Jenkins Developers
Some bits:
  • We have some regression reports probably related to XML 1.1 (JENKINS-49588, fix has not been integrated yet + some other issues)
  • We have an issue with Violations plugin breaking config UIs on new versions (JENKINS-49630). I have not fully triaged it yet, but it may be caused by a core regression somehow
  • We have minor regressions in UI, (JENKINS-49634, JENKINS-49387, JENKINS-49520, ), can be easily backported
  • Same for this localization (JENKINS-49498) - not new regressions, but may need backporting
  • We are still getting new regression reports for JEP-200 (added in 2.102), but I'd guess we want it in LTS anyway
Currently I am not fully comfortable about 2.107.
  • JEP-200 upgrade guidelines will explicitly require users to do a backup before upgrading. There is a risk that the instance does not startup due to a non-fixed plugin
  • But you know, not everybody reads upgrade guidelines and changelogs
  • If we release JEP-200 and XML 1.1 at the same time, there a risk of causing serious configuration fallout for users who did not do backup. JEP-200 can cause a fallout on its own, but with XML 1.1 it may get even worse
Since XML 1.1 fix has not been approved yet, my proposal would be to exclude XML 1.1 from the release. So I vote for 2.104.

BR, Oleg

Daniel Beck

unread,
Feb 23, 2018, 11:49:51 AM2/23/18
to jenkin...@googlegroups.com

> On 23. Feb 2018, at 17:16, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> • We have some regression reports probably related to XML 1.1 (JENKINS-49588, fix has not been integrated yet + some other issues)
>

Since you're arguing for exclusion of the XML 1.1 change, could you elaborate why JENKINS-49588 is related to XML 1.1 in your opinion, and what the other issues are?

JENKINS-49588 AFAICT doesn't have enough information to say for sure, the proposed fix is just flying blind, and everything else related to XML 1.1 I saw was people downgrading and having to `sed -i s/1.1/1.0`. What else was there?

Oleg Nenashev

unread,
Feb 23, 2018, 12:18:09 PM2/23/18
to JenkinsCI Developers


Since you're arguing for exclusion of the XML 1.1 change, could you elaborate why JENKINS-49588 is related to XML 1.1 in your opinion, and what the other issues are?

According to the reporter, the issue appeared after upgrading from a relatively new weekly release (he assumes 2.104) to 2.107. Since there is no other related changes in 2.104+, I suspect XML 1.1 until proven otherwise. It may be something else if they were using another version (e.g. JEP-200 as well).

I do not block selection of 2.107.x, but yes I am concerned about XML 1.1 and Violations plugin issue which is still untriaged.

BR, Oleg

 


--
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/7nR0_kI71xA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3646F859-CABC-4BF8-8805-E214C0602D9E%40beckweb.net.

Jesse Glick

unread,
Feb 23, 2018, 1:17:11 PM2/23/18
to Jenkins Dev
On Fri, Feb 23, 2018 at 12:17 PM, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Since there is no
> other related changes in 2.104+, I suspect XML 1.1 until proven otherwise.

There are all sorts of unreported environmental issues which could
also cause such problems. I do not think a vague suspicion of
involvement with the XML 1.1 format in a couple of bug reports is
sufficient reason to change the version of Jenkins used by thousands
of people.

Oleg Nenashev

unread,
Feb 24, 2018, 6:11:13 AM2/24/18
to JenkinsCI Developers
I do not buy this argument, because at the Governance meeting we explicitly agreed that we may fallback to 2.104 if "we find major problems" (meeting notes).
Two regressions which are not fully triaged (JENKINS-49588, JENKINS-49630) do seem as a major problem.

Anyway, LTS officer (Oliver) will decide whether the current issues are important enough to do so, I just provided my opinion.

For now I invite all parties interested in 2.107 as LTS baseline to help with triaging JIRA issues and reviewing related pull requests.
All core triage work and reviews are driven by the community (often during evenings/weekends), and we will appreciate any contributions which would help to verify the 2.107.x release.

BR, Oleg


--
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/7nR0_kI71xA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

Jesse Glick

unread,
Feb 24, 2018, 8:07:29 AM2/24/18
to Jenkins Dev
On Sat, Feb 24, 2018 at 6:11 AM, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Two regressions which are not fully triaged (JENKINS-49588, JENKINS-49630)
> do seem as a major problem.

Well they do look “major”, and they do seem to be regressions from
something, but it is not at all obvious to me that using 2.104 instead
of 2.107 would solve them. Until we find a way to reproduce from
scratch, or analyze field logs more clearly, it seems premature to
assume that using an earlier weekly will make the LTS better even for
these users.

Oliver Gondža

unread,
Feb 26, 2018, 10:20:13 AM2/26/18
to jenkin...@googlegroups.com
I agree here to stick with the current choice. If we are still not sure
using older baseline will avoid those regressions, I do not see a point
in reconsidering.

--
oliver

Oleg Nenashev

unread,
Mar 27, 2018, 3:09:14 AM3/27/18
to Jenkins Developers
Hi Oliver,

Do you plan to start the backporting thread for 2.107.2?
There is one JEP-200 regression in the core, which potentially impacts all usages of Ant's DirectoryScanner in Remoting Calls: JENKINS-50237. Although we applied a workaround to a plugin which is reported in the PR, but it would be great to have a partial fix in the LTS.

Backporting PR: https://github.com/jenkinsci/jenkins/pull/3372

Thanks in advance,
Oleg

Oliver Gondža

unread,
Mar 27, 2018, 7:18:06 AM3/27/18
to jenkin...@googlegroups.com
On 2018-03-27 09:09, Oleg Nenashev wrote:
> Hi Oliver,
>
> Do you plan to start the backporting thread for 2.107.2?
> There is one JEP-200 regression in the core, which potentially impacts
> all usages of Ant's DirectoryScanner in Remoting Calls: JENKINS-50237
> <https://issues.jenkins-ci.org/browse/JENKINS-50237>. Although we
> applied a workaround to a plugin which is reported in the PR, but it
> would be great to have a partial fix in the LTS.
>
> Backporting PR: https://github.com/jenkinsci/jenkins/pull/3372

The backporting is already in progress, I am behind with announcing it.
The PR is merged, thanks!

--
oliver
Reply all
Reply to author
Forward
0 new messages