Another LTS release needed

130 views
Skip to first unread message

Kohsuke Kawaguchi

unread,
Jan 22, 2013, 1:50:51 PM1/22/13
to jenkin...@googlegroups.com
There were a number of fall-out issues after SECURITY-49. As Jesse found out, some of them are pretty bad, such as JENKINS-16319 and JENKINS-16278.

So I think we need to release 1.480.3.

Any other issues that we need to backport?

--
Kohsuke Kawaguchi

Stephen Connolly

unread,
Jan 22, 2013, 2:06:07 PM1/22/13
to jenkin...@googlegroups.com

Jesse Glick

unread,
Jan 22, 2013, 6:05:36 PM1/22/13
to jenkin...@googlegroups.com
On 01/22/2013 01:50 PM, Kohsuke Kawaguchi wrote:
> Any other issues that we need to backport?

Here is my provisional list of candidates. Not to say I am pushing for all of these to be backported; these are just relatively serious bugs that I know about which
_could_ be backported. Most have fixes in trunk, some not yet (or need more work).

http://jenkins-ci.org/issue/16244 asynchPeople follow-up fix
http://jenkins-ci.org/issue/16342 another asynchPeople follow-up fix
http://jenkins-ci.org/issue/16397 yet another asynchPeople follow-up fix (sigh)
http://jenkins-ci.org/issue/16069 JS problems w/ combo boxes
http://jenkins-ci.org/issue/16278 a SECURITY-49 regression
http://jenkins-ci.org/issue/16319 another SECURITY-49 regression
http://jenkins-ci.org/issue/9679 jnlpCredentials gives a NCDFE (relates to SECURITY-49)
http://jenkins-ci.org/issue/16273 jnlpCredentials not well advertised (relates to SECURITY-49)
http://jenkins-ci.org/issue/6604 race condition in remoting
http://jenkins-ci.org/issue/16341 memory leak in JS proxies

plus a few issues in https://issues.jenkins-ci.org/browse/SECURITY which I will not list here (and that may anyway need to go in at the last minute to avoid publicizing
exploits).

Can we assume that qualified trunk fixes may be optimistically cherry-picked to the ‘stable’ branch and that ‘mvn deploy’ may be used to produce binary snapshot WARs for
people to play with? If we later conclude that a particular fix was not suitable after all, it would be a simple matter to revert it in the branch.

By the way, in the context of 1.480.1 I mentioned that it would be helpful to have a label for LTS backport candidates. Of course you can search for critical/blocker
bugs, but there is no way to tell JIRA to limit this to bugs present in the last LTS, nor to exclude bugs filed without steps to reproduce that were never evaluated.

jgl...@cloudbees.com

unread,
Jan 22, 2013, 6:55:02 PM1/22/13
to jenkin...@googlegroups.com
http://jenkins-ci.org/issue/16215 use If-Modified-Since for tool downloads

jgl...@cloudbees.com

unread,
Jan 22, 2013, 7:04:26 PM1/22/13
to jenkin...@googlegroups.com
http://jenkins-ci.org/issue/15466 JNA issues on Windows

Sandell, Robert

unread,
Jan 24, 2013, 2:53:22 AM1/24/13
to jenkin...@googlegroups.com

Fixed the lock contention problem on Queue.getItems()

 

It is stated as a feature on 1.483 so I don’t know if it can be considered a bugfix for LTS backporting, but if it can get in 1.480.3 we wouldn’t need to maintain our internal fork with a similar fix anymore.

 

 

Robert Sandell

Software Tools Engineer - SW Environment and Product Configuration

Sony Mobile Communications

Message has been deleted
Message has been deleted

Jesse Glick

unread,
Jan 24, 2013, 11:33:50 AM1/24/13
to jenkin...@googlegroups.com
On 01/24/2013 02:53 AM, Sandell, Robert wrote:
> “Fixed the lock contention problem onQueue.getItems()”

Not sure if my posts went through, so:

http://jenkins-ci.org/issue/16468 lock contention in queue
http://jenkins-ci.org/issue/13536 file parameters break build loading

Vojtech Juranek

unread,
Jan 24, 2013, 3:16:27 PM1/24/13
to jenkin...@googlegroups.com
On Tuesday 22 January 2013 19:06:07 Stephen Connolly wrote:
> Is https://issues.jenkins-ci.org/browse/JENKINS-16069 back ported already?

backported

Vojtech Juranek

unread,
Jan 24, 2013, 3:16:40 PM1/24/13
to jenkin...@googlegroups.com
backported

Vojtech Juranek

unread,
Jan 25, 2013, 2:13:49 PM1/25/13
to jenkin...@googlegroups.com
Backported:

JENKINS-16069
JENKINS-16468
JENKINS-13536
JENKINS-6604
JENKINS-16244
JENKINS-16397
JENKINS-16278
JENKINS-16273
JENKINS-16319
JENKINS-9679
JENKINS-16342

those in trunk I backported because were related to SECURITY-49 and need
immediate fix or I consider the fixes as low risk (while problems they fix are
IMHO quite serious).

The only one I don't understand is
JENKINS-16341 and 08efdf5d3ab9
- does replacement of Set by Array reduce memory footprint in any substantial
way?


> plus a few issues in https://issues.jenkins-ci.org/browse/SECURITY which I
> will not list here (and that may anyway need to go in at the last minute to
> avoid publicizing exploits).

yes, I'd also expect these to be cherry-picked just before the release

> Can we assume that qualified trunk fixes may be optimistically cherry-picked
> to the ‘stable’ branch and that ‘mvn deploy’ may be used to produce binary
> snapshot WARs for people to play with?

the artifacts like WAR should be available on [1] (if it fails, I can provide
it on our public Jenkins instance). Once backports are done, I'd expect RC
will be published and there will be some time for testing.

> By the way, in the context of 1.480.1 I mentioned that it would be helpful
> to have a label for LTS backport candidates.

+1, not sure if JIRA didn't provide tags by time when we setup processes for
LTS or there were some other objections, but obviously I'm not able to track
all JIRAs and asking on dev-list is not very effective.

[1] https://ci.jenkins-ci.org/job/jenkins_lts_branch/

Jesse Glick

unread,
Jan 25, 2013, 2:24:00 PM1/25/13
to jenkin...@googlegroups.com
On 01/25/2013 02:13 PM, Vojtech Juranek wrote:
> The only one I don't understand is
> JENKINS-16341 and 08efdf5d3ab9
> - does replacement of Set by Array reduce memory footprint in any substantial way?

No, the point is the calls to intern(), since a lot of the copied objects are common String’s. But 08efdf5d3ab9 can at best reduce the magnitude of the leak, and while it
seemed to help from interactively testing (jconsole), the functional test does not demonstrate much difference. A more sophisticated fix is needed anyway, probably using
a ping timeout as discussed later in the issue.

>> it would be helpful to have a label for LTS backport candidates.
>
> +1

Based on experience dealing with backport proposals for NetBeans, I would suggest a label scheme like this:

1.480.3-candidate (anyone can add if they think appropriate)
1.480.3-fixed (-candidate changed to -fixed by merger)
1.480.3-rejected (-candidate changed to -rejected if decided to be inappropriate)

Then you can easily search for open 1.480.3 candidates, and if we ever did a 1.480.4 you could see if there were still some .3 candidates left over and since fixed in
trunk, etc.

Vojtech Juranek

unread,
Jan 26, 2013, 3:05:50 PM1/26/13
to jenkin...@googlegroups.com
Backported:
JENKINS-16341
JENKINS-16215
JENKINS-15466

> 1.480.3-candidate (anyone can add if they think appropriate)
> 1.480.3-fixed (-candidate changed to -fixed by merger)
> 1.480.3-rejected (-candidate changed to -rejected if decided to be
> inappropriate)

sounds good to me. Has anybody else any objections to use this approach?

Jesse Glick

unread,
Jan 26, 2013, 4:19:42 PM1/26/13
to jenkin...@googlegroups.com
On 01/26/2013 03:05 PM, Vojtech Juranek wrote:
> JENKINS-15466

Well just the diagnostics, I think; an actual fix is still pending.

Vojtech Juranek

unread,
Jan 27, 2013, 7:11:20 PM1/27/13
to jenkin...@googlegroups.com, k...@kohsuke.org
Hi,
backports are done, build passes without failures [1]. Could you please
release RC for manual testing?
Thanks
Vojta

[1] https://ci.jenkins-ci.org/view/Jenkins%20core/job/jenkins_lts_branch/85/

Vojtech Juranek

unread,
Jan 28, 2013, 4:27:42 AM1/28/13
to jenkin...@googlegroups.com
> > 1.480.3-candidate (anyone can add if they think appropriate)
> > 1.480.3-fixed (-candidate changed to -fixed by merger)
> > 1.480.3-rejected (-candidate changed to -rejected if decided to be
> > inappropriate)
>
> sounds good to me. Has anybody else any objections to use this approach?

btw: added to agenda for next governance meeting [1]

[1] https://wiki.jenkins-
ci.org/display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-
Feburary6thMeeting

Chris Selwyn

unread,
Jan 28, 2013, 5:25:11 AM1/28/13
to jenkin...@googlegroups.com
We would really appreciate it if https://issues.jenkins-ci.org/browse/JENKINS-15418 could be included into the new LTS.

Would that be possible?

Chris

jgl...@cloudbees.com

unread,
Feb 6, 2013, 4:08:40 PM2/6/13
to jenkin...@googlegroups.com
Another candidate that I do not think was mentioned before:

http://jenkins-ci.org/issue/15494 JS error: Cannot read property 'firstChild' of null

jgl...@cloudbees.com

unread,
Feb 7, 2013, 10:35:59 AM2/7/13
to jenkin...@googlegroups.com
http://jenkins-ci.org/issue/15493 Jelly TagScript problem

(which might already be implicitly fixed in branch by virtue of being included in a Stapler update, not sure)

jgl...@cloudbees.com

unread,
Feb 7, 2013, 10:44:13 AM2/7/13
to jenkin...@googlegroups.com
On Thursday, February 7, 2013 10:35:59 AM UTC-5, jgl...@cloudbees.com wrote:
http://jenkins-ci.org/issue/15493 Jelly TagScript problem

 Never mind, was already in 1.480.1, changelog just failed to mention it. 

Jesse Glick

unread,
Feb 22, 2013, 3:36:22 PM2/22/13
to jenkin...@googlegroups.com
On 01/28/2013 04:27 AM, Vojtech Juranek wrote:
>>> 1.480.3-candidate (anyone can add if they think appropriate)
>>> 1.480.3-fixed (-candidate changed to -fixed by merger)
>>> 1.480.3-rejected (-candidate changed to -rejected if decided to be inappropriate)
>>
>> sounds good to me. Has anybody else any objections to use this approach?
>
> added to agenda for next governance meeting

Guess that did not happen. In the meantime I am going to take the liberty of using these labels for the 1.480.x line; if some other system (or no system) is decided on
later, it is easy enough to undo after all.

KEVIN FLEMING (BLOOMBERG/ 731 LEXIN)

unread,
Feb 22, 2013, 3:38:05 PM2/22/13
to jenkin...@googlegroups.com
Yeah... the appointed time for the governance meeting came and went without any discussion.
--
You received this message because you 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.
For more options, visit https://groups.google.com/groups/opt_out.



Reply all
Reply to author
Forward
0 new messages