create-kernel-tasks: Work around spin 1 Launchpad bug
When looking up workflow trackers to check for exising ones there is a
difference between spin #1 and later ones. The reason why is somewhat
lost in history. While for later spins the library is called with a set
of all cycle tags, we pass an empty list for the initial spin.
This gets translated by the library into a search for all workflow tasks
which have a "kernel-release-tracking-bug-live" tag. Right now this
seems to return about 4000-5000 entries when done via the web page. The
API call however runs into a timeout and returns a Launchpad Oops.
Right now the simplest solution is to modify create-kernel-tasks to pass
in the cycle tag for spin #1 as well. Which also speeds up the runtime a
lot.
Signed-off-by: Stefan Bader <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
create-kernel-tasks: Work around spin 1 Launchpad bug
When looking up workflow trackers to check for exising ones there is a
difference between spin #1 and later ones. The reason why is somewhat
lost in history. While for later spins the library is called with a set
of all cycle tags, we pass an empty list for the initial spin.
This gets translated by the library into a search for all workflow tasks
which have a "kernel-release-tracking-bug-live" tag. Right now this
seems to return about 4000-5000 entries when done via the web page. The
API call however runs into a timeout and returns a Launchpad Oops.
Right now the simplest solution is to modify create-kernel-tasks to pass
in the cycle tag for spin #1 as well. Which also speeds up the runtime a
lot.
Signed-off-by: Stefan Bader <email address hidden>
Our sample cranky configuration file provides defaults could be
considered dangerous. Additionally, our cranking the kernel doc uses a
different path configuration for examples which is very confusing for
new-starters.
- update config to use a safer (though more costly in storage) defaults
- add note to cranking doc to call out why the paths may differ.
Signed-off-by: Cory Todd <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
stable-tools: Add intial stable patchset scripts to stable-tools
Add git-stable-extag and stable-check-reverts into a top level directory
where we can put tools for processing stable patchsets and other
stable related tasks.
This would differ from the "stable" directory in that it would be for tools
not related directly to swm and cycle management.
After running a `cranky checkout lunar:linux-kvm`, the
`linux-kvm-restricted-modules/` directory is not created but instead
the `linux-lrm/` folder name is used. After asking to the team,
this seems to be the new name in use for restricted modules.
Also, the `-DERIVATIVE` suffix is gone.
Reflect these name changes into the docs.
Note: this change makes the docs inconsistent, as linux-oracle
still seems to use the `linux-restricted-modules` name.
TODO: use something else than linux-oracle for the examples.
Signed-off-by: Agathe Porte <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Roxana Nicolescu <email address hidden>
Signed-off-by: Agathe Porte <email address hidden>
