Use NOTBUILT rather than GREY when a job has not yet been built.
[FIXED JENKINS-18024] Avoind NPE when checking if reason why in the queue has beed changed
creating an RC branch
the trunk is toward 1.518-SNAPSHOT
Trying to explain what “People” means.
[FIXED JENKINS-18118] Introduced UserAvatarResolver.resolveOrNull to properly produce fallback icon URL.
[FIXED JENKINS-18119] Work around timing issue in sortable object.
Note that when workaround is active, table will not get sorted properly.
Probably OK since tables with large contents that *need* sorting probably take longer to finish rendering.
[JENKINS-18074] Updated comment.
Merge pull request #778 from jglick/Job-getIconColor-unbuilt

Use NOTBUILT rather than GREY when a job has not yet been built
+1 from @kutzi and no comment from @kohsuke, so I hope this is uncontroversial.
Merge pull request #785 from vjuranek/JENKINS-18024

[FIXED JENKINS-18024] Avoid NPE when checking if reason why in the queue has been changed
[JENKINS-18024] Noting.
Attempting to be more robust against problems initializing this class.
https://jenkins.ci.cloudbees.com/job/core/job/jenkins_main_trunk/896/testReport/junit/hudson.tools/ToolLocationNodePropertyTest/testFormRoundTrip/
java.lang.NoClassDefFoundError: Could not initialize class hudson.model.ComputerSet
	at jenkins.model.Jenkins.getComputer(Jenkins.java:1107)
[FIXED JENKINS-16301] Optimized Fingerprint.save.
[JENKINS-16301] Need to create parent directory of fingerprint file too.
[JENKINS-15652] More clearly distinguishing the three asserts.
[JENKINS-15652] Reproduced at least one assertion failure in a unit test.
[FIXED JENKINS-15652] “Solving” errors by just return null from ALLRM.search and reducing to one-line warnings.
@kohsuke confirms that the intent of throwing AIOOBE was to track down definite code errors;
but in at least some known occurrences of this bug, the problem is invalid data:
build records on disk with <number>s that are duplicated and/or out of order.
Since that violates the precondition of the class, we do not pretend to successfully search for such records.
At some point it would make sense to have the code detect anomalous conditions and initiate a builds folder cleanup.
Take only the last build of a given number, and discard any earlier with higher number.
I.e. just set <number> to 0 or something and ignore such builds, or rename build.xml to build-broken.xml.
JUnit 4.
[JENKINS-17713] Preparing unit and functional test coverage.
Bump mailer version to 1.5