Patch reason tracking

Josh Boyer jwboyer at fedoraproject.org
Tue Nov 19 02:40:06 UTC 2013


Hi All,

Every month I'm trying to publish a Fedora Kernel patch report that
lists all of our patches and why we are carrying them.  Thankfully,
the past couple of times I've done this it's been pretty clear that
for the most part we're just carrying fixes queued up to head to Linus
soon.

However, it also means I have to track down the status of that patch
every month.  I've been trying to keep PatchList.txt up to date, but
that isn't scaling very well as it's easy for people to forget to add
patches to it or remove them when we drop the patch.  To help this
tracking, I'd like to push the status information into each patch
itself.  What I propose is basically to fields at the top of each
patch:

Bugzilla:
Upstream-status:

The first is fairly self-evident.  It just list the Red Hat Bugzilla
number associated with the patch.  If there isn't one, just put N/A.

Upstream-status is fairly free-form at the moment, but the intention
is to briefly capture when the patch is going to hit Linus' tree, or
some other subsystem tree.  This can be done fairly simply e.g.:

Upstream-status: 3.13
Upstream-status: queued in net-next for 3.14
Upstream-status: <link to lkml or other mailing list thread>
Upstream-status: Fedora Mustard

Eventually I plan on writing a tool to scrape this information
together for the report, but I wanted to get some feedback on the two
fields for now.  Do they seem pretty straight-forward?  Do you have
questions or other ideas/suggestions?

If nobody screams much, I'll likely update all the patches in F20 and
rawhide this week (I've already done some of them.)  If we eventually
get to some kind of patchwork style tracker, this shouldn't interfere
at all and might actually help reviewers.

Thanks.

josh


More information about the kernel mailing list