Added logging more liberally, and fixed the problem.
The root cause was that when the mouse enters a hot spot, I wasn't cancelling the previous delayed hide timer.

This fix eliminates the need for the hack in the hide method where I was testing if the mouse was still over the hotspot.

Using l:confirmationLink instead of AbstractItem/delete.jelly and AbstractProject/wipeOutWorkspace.jelly.

Expanded MockFolder to be a ViewGroup so that it is possible to test views inside folders,
and generally fixed it to service Stapler hierarchies properly so that WebClient-based tests can work.

[FIXED JENKINS-15340] Ask for confirmation before reloading config from disk, as it may be expensive.
First of all, /reload should require POST (also prevents XSS DoS attacks).
Adding <l:confirmationLink> to encapsulate a link that requires confirmation upon clicking.
Allowing a ManagementLink to request confirmation (also implying POST); could be used also for e.g. /quietDown.
Enhancing <l:task> to support confirmation as well, and honoring this in context menu items.

(Not touching the icon since I do not feel like playing with Inkscape; would be a nice pull request for somebody.)

Revert "[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only."

This reverts commit 3a6de84f.
(Regressed JENKINS-15666.)
Conflicts:

	changelog.html

This changes introduces a 'recurse' option on ListView that allows to
match using regexp jobs contained inside folders.
The full name of the
job is matched so / can be used as separator.
This allows slice and dice of jobs contained in different folders.

[FIXED JENKINS-17451] "projects tied to slave" shows unrelated maven module jobs. shows TopLevelItem only.

Root cause seems to be broken serial form of FingerprintAction, probably caused by lazy loading.

Also provide proper overrides of ParameterValue.getShortDescription, rather than delegating to toString.

Don't break Windows XP, fall back gracefully to no-op.

[FIXED JENKINS-7970] JUnit result archiver should only fail builds if there are really no results - i.e. also no skipped tests.

Instead, it shows a small 'v' icon to the right that needs to be clicked
to open a context menu.

[FIXED JENKINS-17330] FilePath.installIfNecessaryFrom should avoid routing download over remoting channel.

[FIXED JENKINS-7291] Permit flyweight tasks to run on master even when it has zero configured executors.

Always adding Computer for master as a fallback

The original proposed fix for JENKINS-7291 creates a Computer object
transitively. This seems unwise as it violates the design of Computer
as stated in the javadoc, and for example we can end up creating two
Computers for the master.

I think a better fix is to create a Computer for the master all the
time, even if there's no executors configured. The discrimination in
Queue.makeBuildable would ensure that such phantom Computer is only used
as a last resort (statistically speaking).

I've also tweaked executors.jelly a bit. I simplified it somewhat
based on the idea that "if there's only one computer to show, the
context is likely making it obvious".

(I must be missing the intricacy in the current code.)

Originally developed in a branch at
2c5b57fcc1f39ed39057254e802f4183db5aa0dc then squashed for clarity.

[FIXED JENKINS-17331] PerJobLocalRepositoryLocator should prefer the MavenModuleSetBuild.workspace for single-module builds.

[FIXED JENKINS-13154] AnnotationMapper bug was causing massive lock contention when saving fingerprints.

Fixed the throughput problem between master/slave communication.
This fix contains two independent problems.

One was in the remoting. During a large sustained data transfer
(such as artifact archiving and large test reports), the way we
were doing flow control and ACK-ing were penalizing us badly.
I improved the flow control algorithm in remoting 1.23, and also
increased advertised window size so that the transfer can saturate
available bandwidth even when a latency is large. (And unless
the reader side is excessivesly slow, this shouldn't increase
any memory consumption.)

The other fix was in trilead-ssh2, which is our SSH client
implementation used by ssh-slaves plugin. The buffer size for flow
control was too small. I improved the way buffering is done to reduce
the memory footprint when the reader closely follows the writer, then I
increased the advertised window size. Again, this shouldn't increase
memory consumption (in fact it'll likely actually reduce them) unless
the reader end gets abandoned.

On my simulated latency-injected network, the sustained transfer rate is
now on par with scp. We win for smaller files because of the TCP slow
start penality that scp would incur, and we lose a bit as files get
larger due to additional framing overhead.

If you have manually extracted slave.jar and placed them on slaves, you
need to update them to 2.23 to see the performance benefits.