cranky: crl/config -- Config.lookup() must not modify Config.config
Currently, the lookup() method modifies Config.config which is bad, the
config dict should not be modified. Fix that by making a deep copy, but
for that, Config.config must always be a dict. Fix that as well, for
the case when we create an instance like Config(data="").
cranky/annotations-tools: add unit test for the todo note update
Add a unit test to verify the automatic todo note update: when a config
in a derivative changes we want to make sure that the note imported from
the parent is updated for the derivative, therefore we add an explicit
TODO note to mark that the config change requires a proper justification
(link to a bug tracker, comment, etc.).
cranky/annotations-tools: add unit test for the todo note update
Add a unit test to verify the automatic todo note update: when a config
in a derivative changes we want to make sure that the note imported from
the parent is updated for the derivative, therefore we add an explicit
TODO note to mark that the config change requires a proper justification
(link to a bug tracker, comment, etc.).
Signed-off-by: Andrea Righi <email address hidden>
stable-tools: Add script to check for existing critical fixes
This tool is meant to be run when preparing an upstream stable patchset.
It will check for potentially critical fixes in future patchsets on the
same branch, that fix issues in patchset you are currently working on.
What is considered critical is based on a set of regular expressions
that might produce some false positives and miss actually critical
fixes.
The script will present critical fixes it detected in a nice way with
some additional information. The user may then decide whether it is
reasonable to apply the fix ahead of time.
Ideally we would be able to avoid applying patches that severely break
the kernel even though a fix is readily available.
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Andy Whitcroft <email address hidden>
stable-tools: Add script to check for existing critical fixes
This tool is meant to be run when preparing an upstream stable patchset.
It will check for potentially critical fixes in future patchsets on the
same branch, that fix issues in patchset you are currently working on.
What is considered critical is based on a set of regular expressions
that might produce some false positives and miss actually critical
fixes.
The script will present critical fixes it detected in a nice way with
some additional information. The user may then decide whether it is
reasonable to apply the fix ahead of time.
Ideally we would be able to avoid applying patches that severely break
the kernel even though a fix is readily available.
Signed-off-by: Manuel Diewald <email address hidden>