Created new fork and commit mesasges to local branch to it:

commit dab42e57ce1a1b9ca1b2f8251f2d89127cd69d04
Author: tim.brown5 <tim.brown5@hp.com>
Date:   Mon Jan 27 17:40:43 2014 +0000

    Added the ability to specify a PollInterval value - to stop the plugin spamming the logs. Also Fixed some typos in the field titles in config.jelly.

commit 81558c521857bea4c0d0c6c951b759f8e28bdab4
Author: brownt <tim.brown5@hp.com>
Date:   Thu Jan 23 15:10:27 2014 +0000

    Changed the tile of check box from 'Block execution of remote builds while other builds are running.' to 'Block triggering of remote builds while other builds are running.' to better describe what it does.

commit b78f021cd0b7ddccd3e84fc2fc2758fd8d92a092
Author: brownt <tim.brown5@hp.com>
Date:   Thu Jan 23 15:08:25 2014 +0000

    Added to checkBoxes to allow toggling of the following fnctionality:
    - Block triggering of remote builds while other builds are running.
    - Block build step until remove build is complete.

    The first gets round an issue where multiple jobs are all trying to launch jobs at once and filling up the build queue on the remote server. This causes an issues because when jobs are in the queue you cannot get their status. Another way to solve this would be to assume that the job is in the build queue and 'qait' until you can access the job's build page.

    The second allows the user to make the local job block until the remote job has finished (and so set the status of the local job to that of the remote job). This is a fix for issue JENKINS-20828. If you are using this feature it's best to also use the feature above, as otherwise your builds will fail when remote builds you have triggered are waiting in the build queue.

    This works best if only one job is triggering builds on a remote job. This is because is two builds trigger a job at the same time it is possible for them both to think next next build is the one they triggered... A solution to this could be comparing the parameters??

commit 22983d13fc8a1b63b3686facfcd10d31d51f074a
Author: brownt <tim.brown5@hp.com>
Date:   Wed Jan 22 15:37:41 2014 +0000

    Added 'fix' as describe in: https://issues.jenkins-ci.org/browse/JENKINS-20828

    *Feel free to ignore this branch if you are working on this yourself. Also free free to use this code as you see fit.*

    "I have created a workaround/fix for this issue. My code does the following:

        get the nextBuildNumber from the job
        trigger the build
        check that next build number has increased by one - this means we know that the only job triggered is the one we triggers, otherwise we error
        then wait for the job with the build number above to start
        then wait for the job with the build number above to finish and return the result.

    I can share the code if you are interested
    *I also split out the HTTPRequest code into a method, so you can call different URLs with different methods (to simplify the communication with the remote server).

    I do agree however, it would be a lot easier if the trigger call returned the build number of the job it's just triggered. Could raise an issue to see if this can be done?
    "

    There are issues with this 'fix' when multiplem jobs are triggering the same remote job:
    1. It blocks all the time - would probably need to add a toggle button to turn the blocking on/off
    2. It returns failure if it tries to check on a remote job and the job has not started yet - as it goes to the job
    3. If two jobs are launched at the same time they can both pickup the same job ID - so they

    - These issues shouldn't affect quiet environments, but ones that kickoff a lot of the same jobs in a few seconds will see issues. There also might be issues if the remote job takes a long time. I cannot think of a way to get round these issues at the moment...

    To test this I setup multiple local jobs all triggering one remote job. When running them all one at a time there were no issues, but running them all at once there were issues.