diff options
| author | Luis R. Rodriguez <lrodriguez@atheros.com> | 2010-05-21 17:35:40 -0700 |
|---|---|---|
| committer | Luis R. Rodriguez <lrodriguez@atheros.com> | 2010-05-21 17:35:40 -0700 |
| commit | 70c4c37c79e507f733d7aa2746390ce3ddf876c5 (patch) | |
| tree | 35bd9dedaf7dd42e29f35e2efbedb1b161f9d3fc /linux-next-pending | |
| parent | 3442c9352b56783f46a0bd92cc7400222dff8f5c (diff) | |
compat-wireless: add linux-next-pending, crap patch dirs and nagometer
Sometimes you have no other option but to carry around patches.
This can happen for a variety of reasons. Ultimately testing of code
cannot happen on the kernel maintainer's clock but on your own.
This expands the idea of the linux-next-cherry-pick patch directory
on compat-wireless to also allow for patches to be merged which are
posted to some mailing list but pending merge due to some reasons
(merge window is a good example). It also adds a crap patch directory
for those really nasty situations you can run into where you have
no other option but to give someone a release with some delta even
if the patch is not yet posted anywhere.
The focus should always be upstream though so to avoid these
situations we will also provide code metrics to indicate to
the package maintainer how much code came from each directory,
including the backport code to support older kernel releases.
Maybe we should add the code-metrics.txt file as a print out
on the compat module load :)
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Diffstat (limited to 'linux-next-pending')
| -rw-r--r-- | linux-next-pending/README | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/linux-next-pending/README b/linux-next-pending/README new file mode 100644 index 00000000..cc531b22 --- /dev/null +++ b/linux-next-pending/README @@ -0,0 +1,17 @@ + +compat-wireless linux-next-pending patches +========================================== + +You must have a really good reason to be adding files +in this directory. The requirement is your patches must have +been posted to a public mailing list for the subsystem you are +working on. Each patch you add here must have a really good +explanation on the top of the file which clarifies why the +patch has not yet been merged. + +We try to avoid having patch files because but we understand +if you might because you need to test code posted but not yet +merged into linux-next or a stable kernel release. This can happen +often during the merge window, when the maintainers are unavailable, +on vacation, suck at what they do, or for any other uncontrollable +reasons. |