| 1 |
dannf |
16 |
A boilerplate for tracking the status of patches across Debian Kernel trees. |
| 2 |
|
|
dannf> should anything go above this line? |
| 3 |
|
|
dannf> should we use debian-style rfc822 for this for machine readability? |
| 4 |
|
|
====================================================== |
| 5 |
|
|
Candidate: (##NEEDED## | CAN-XXXX-XXXX | N/A) |
| 6 |
|
|
URL: dannf> What makes a URL different than a Reference? Is it always mitre's? |
| 7 |
|
|
Reference: CONFIRM:##URL## dannf> what does CONFIRM mean? |
| 8 |
|
|
Reference: MISC:##URL## dannf> what does MISC mean? |
| 9 |
|
|
Description: ##NEEDED## dannf> can a single description work for the cve, |
| 10 |
|
|
dannf> the changelog, and the DSA? |
| 11 |
|
|
dannf> should this use debian/control style multiline? |
| 12 |
|
|
dannf> should we have a short description? |
| 13 |
dannf |
17 |
fixed-upstream: [version(, version)*] |
| 14 |
|
|
2.6.13: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff] |
| 15 |
|
|
2.6.12: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff] |
| 16 |
|
|
2.6.8-sarge-security: (pending [(version)]|released [(version)]|N/A)[, backported][, patch-name-used.diff] |
| 17 |
|
|
... one line for each currently maintained tree |
| 18 |
dannf |
16 |
|
| 19 |
|
|
dannf> what does backported mean? the patch didn't apply & needed munging, |
| 20 |
|
|
dannf> or just that we used a patch intended for a newer tree, that may have |
| 21 |
|
|
dannf> applied cleanly? |
Parent Directory
| 
Revision Log