Patch reason tracking

Josh Boyer jwboyer at fedoraproject.org
Wed Nov 20 17:25:28 UTC 2013


On Wed, Nov 20, 2013 at 12:08 PM, Adam Jackson <ajax at redhat.com> wrote:
> On Mon, 2013-11-18 at 21:40 -0500, Josh Boyer wrote:
>> 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.
>
> Only question I have is why/whether this needs to be rhbz, or if we
> could just do arbitrary bz urls.  I don't really mind either way though.

Arbitrary bugzilla URLs would be fine instead of just a bug number.
Whatever gives us the most information relevant to the patch.

Originally I had thought I would have some tooling to parse this field
and set the bug in MODIFIED state upon commit, but thinking about it
some that seems both excessive and error prone.  There is often more
than one patch needed per bug, it might be needed on more than one
branch, etc.  So I think we'll keep the fields informational for now
and bug URLs seems to fit that better.

josh


More information about the kernel mailing list