I had tow motivations of getting rid of the All view
The All view is quite annoying don't you think? After using Hudson for a while you have tens/hundreds of jobs lined up in a huge list - who needs that right.
I wanted a "hidden jobs section" - Jobs no one but myself (and who ever needs access to it) can see.
As a big fan of hudson-ci I would like to take a note of the most commonly used hudson plug-ins (at least by me) needed in order to maintain a good build environment.
This list was collected as part of my experience in the last couple of years. I am sure your may differ then mine mine :).
In one of my previous projects I was asked to setup the environment / automate integration tests (Referred to as Itest from now on) which required a machine with 2 CPU's & 5 GB RAM, this means that in any case a developer wishing to run Itests will never be able to run them locally, and will have to use some existing server.
The problem with my previous statement is that the developer, whilst checking his tests will be busy most of the time preparing his Itest environment, rather then checking the integrity of his tests, need I say that the fact we need 2 CPU's & 5GB RAM means the server takes time to load and only once it is up you can start testing.
If you are during a major change in your build configuration, backup your configurations and you can restore from the backup when / if needed.
It is just much more elegant then copying those XML file's and editing them by hand when in comes to restoring your configuration... believe me I've been there ... (tested with Hudson 1.327 and 1.335 which is one release since the latest).
If you wish to "hang on" to a certain plugin which shipps with hudson.war just unpin it in the Manage Hudson >> Manage Plugins page - this option is availabe sine 1.374 release (and you can always grab the latest @: latest)
See full explanation below quoted from hudson wiki:
Yesterday I upgraded hudson to the greatest an latest which was a seamless upgrade.
A very obvious change in the Job configuration form was added instead of "Tie Build to a node":
There is now "Restrict where this project can be run":
The disadvantage in this feature is if you want to a build to a node you need to know its name / node group name prior to the actual configuration. The Advantage of this feature is you can be more specific in where you want you build to run and with a large number of slaves this is quite important, Please note: "old" jobs aren't affected of this change.
Version 1.371 of Hudson was released Aug 9 and introduced a weird "side affect". A Job configuration form will save the data to the filesystem, but will not return to the Job page - this doesen't braek anything but is just annoying.
Early adapters feel free to go ahead and update to 1.372 (download here) which I tested and works like a charm + fixes this issue introduced in 1.371 release.
If you wish to "hang on" to a certain plugin which shipps with hudson.war just unpin it in the Manage Hudson >> Manage Plugins page - this option is availabe sine 
Version 1.371 of Hudson was released Aug 9 and introduced a weird "side affect". A Job configuration form will save the data to the filesystem, but will not return to the Job page - this doesen't braek anything but is just annoying.
) make sure you install it - it isn't installed by default on RHEL!.