Another LTS release needed

[Kohsuke Kawaguchi]

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]

Is https://issues.jenkins-ci.org/browse/JENKINS-16069 back ported already?

[Jesse Glick]

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]

http://jenkins-ci.org/issue/16215 use If-Modified-Since for tool downloads

[jgl...@cloudbees.com]

http://jenkins-ci.org/issue/15466 JNA issues on Windows

[Sandell, Robert]

“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

[Jesse Glick]

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]

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]

backported

[Vojtech Juranek]

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]

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]

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]

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]

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]

> > 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]

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]

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]

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]

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]

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)]

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.