compat-wireless: add support for generating pending-stable/ fixes

Often right before the merge window we get a block on non
oops/regression fixes for stable fixes. Some stable fixes
often get propagated afterwards during the extraversion
maintenance of the kernels. Right before the merge window
circa rc4 and rc5 subsystem maintainers get pegged if they
throw in non oops/regression fixes for Linus or their
respective upstream maintainer. While this makes sense
for tree management and stable release considerations we
still need to get users some stable patches propagated.
We can achieve this in compat-wireless with the -s option to
./scripts/admin-update.sh which this patch implements. You
will need to use a stable branch of compat-wireless, point
it to a stable git tree, and have present a linux-next git
tree. The -s option will get your $(git describe --abbrev=0)
from your stable tree and then get all pending fixes via:

git format-patch --grep="stable@kernel.org" \
	-o pending-stable/ $(git describe --abbrev=0)..HEAD $WSTABLE

Where WSTABLE is:

export WSTABLE="
        net/wireless/
        net/wireless/
        net/mac80211/
        net/rfkill/
        drivers/net/wireless/
        net/bluetooth/
        drivers/bluetooth/
        drivers/net/atl1c/
        drivers/net/atl1e/
        drivers/net/atlx/
        include/linux/nl80211.h
        include/linux/rfkill.h
        include/net/cfg80211.h
        include/net/regulatory.h
        include/net/cfg80211.h"

What this does is get us all pending stable fixes on linux-next.git
not yet merged onto Linus' tree. This lets us hurry in stable fixes
for users for stable releases of compat-wireless based on the RC
series. This accelerates the pace of fix propagation right before
the merge window.

To generate and apply your own stable fixes to your stable compa-wireless
releases you will then use:

./scripts/admin-updates.sh -s

The -s both generates new pending stable fix patches applies the
patches from the pending-stable/ directory. I'm up to support stable
releases with pending-stable/ applied, not sure if its worth it to
have two releases, one with it and one without buf if there are
considerations for this please let me know and I'll just make two
releases. For now I'll make the releases with the stable patches
merged with the requirement they must at least be on the linux-next.git
tree to promote upstreamabilty (is that a word?).

If you want to review the pending-stable/ picked patches check out the
pending-stable/ directory on the respective stable compat-wireless release.
Note that for non-stable releases you can also use the linux-next-cherry-picks/
directory, that gives distributions/vendors the flexibility to cherry pick out
non-stable fixes from linux-next.git for a stable release. For the big
fat warning as why this should be avoided check the README on that directory.

The pending-stable/ directory may also help the stable team maintainers on
their crusade when applying patches onto stable, it also means we will
need respective backports at least to Linus' tree for each stable patch.
Right now I get 23 pending stable patches based on today's linux-next.git
and Linus' v2.6.36-rc5 tag, which *should* in theory get propagated to
the first extraversion release of the kernel onto v2.6.36.1 (we'll see!).

Cc: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org
Cc: stable-review@linux.kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

1 files changed, 23 insertions, 0 deletions

diff --git a/pending-stable/README b/pending-stable/README
new file mode 100644
index 00000000..d3669779
--- /dev/null
+++ b/pending-stable/README
@@ -0,0 +1,23 @@
+compat-wireless pending-stable/ patches
+=======================================
+
+Often right before the merge window we get a block on non
+oops/regression fixes for stable fixes. Some stable fixes
+often get propagated afterwards during the extraversion
+maintenance of the kernels. Right before the merge window
+circa rc4 and rc5 subsystem maintainers get pegged if they
+throw in non oops/regression fixes for Linus or their
+respective upstream maintainer. While this makes sense
+for tree management and stable release considerations we
+still need to get users some stable patches propagated.
+
+This directory is there to help with that. Only patches
+which have been merged into linux-next.git will be included
+in this directory which means you must post it and the maintainer
+should have merged it and Stephen would have picked it up.
+
+This directory will always be empty for bleeding edge
+releases as bleeding edge releases are always based on
+linux-next already. This directory only makes sense for
+stable release of the kernel, and it we will always try
+to use it, in case there are stable fixes not yet propagated.