From: Ben Hutchings <ben.hutchings@...>
The Readme file mentions that you need two remote branches (torvaldsSo the README should refer to that file rather than repeating a list of
and stable) defined on the ../kernel directory by default. However,
that didn't seem enough because conf/remotes.yml also includes a
remote branch "cip".
OK, I sent a patch for README. I also sent a patch for what it looks a small copy&paste mistake.
I added a "cip" remote branch, but then I got an error when importingimport_stable.py doesn't update the "torvalds" remote, and neither did
(see draft). Could you help me understand why do I need the CIP
remote branch if ../kernel already has the CIP information? It seems
I am doing something wrong.
you, so you don't have all the expected tags.
I suppose that import_stable.py should do that.
OK, I sent a patch to address that. However, you were explicitly skiping "torvalds". Do you want me to add some command option such as "--skip-remote=torvalds".
I have also written a new patch that adds configured remote branches automatically if they are not present.
Question: The base git repository (../kernel) doesn't look like it is needed for anything other than storing remotes. Is that correct?
If "../kernel" does not exist, should I automatically create one and initialize the repository? (mkdir ../kernel; git init .).
For now, I sent a patch that checks for the existance of ../kernel
I am still trying to figure out the correct workflow. I have thoughtNot yet but it would probably not be hard to do.
of at least two use cases:
1) CIP kernel maintainer: (s)he wants to know whether there are
debian/ubuntu CVEs pending on his branch.
$ ./scripts/report_affected.py linux-4.4.y
2) Product engineer: he wants to know which CVEs are pending on the
kernel since he shipped the device. If the CVEs are critical he may
decide to create a new release and update the device.
$ ./scripts/report_affected.py linux-4.4.y:v4.4.176-cip31<-- is
something like this possible?
OK, I will work on that.
Also, I wanted to know how new issues are added. I am guessingYou don't need to run validate.py immediately after an import, unless
something like this:
-> automatically adds yml files in issues/
-> checks all yml syntax
you suspect a bug in the importer. It's only important after hand-
$ vi issues/CVE-xxx <-- edit by hand those with syntax errors, orYou would edit by hand if you see that some imported information is
incorrect or there is missing information.
$ ./scripts/validate.py <-- repeat validate until no errors appearYAML allows the same thing to be written in different ways, e.g.
$ ./scripts/cleanup.py <-- correct indentation or spaces?
bracketed vs bulleted lists. The purpose of cleanup.py is to make the
syntax and ordering of items consistent with the importers, to reduce
"noise" in diffs.
Thanks, I added this informaton to my Quickstart. I will upload it to the wiki when I think it's ready.