Patch tracking system - again...

Steven Edwards winehacker at gmail.com
Fri Feb 8 01:51:15 CST 2008


Hi,
I'm not sure if this would even really be of use with most of the
development being done on git anyway, but after re-reading the
governance thread when the point of patch tracking was brought up, It
got me thinking. last time around it got shelved as normal due to not
wanting to disrupt Alexandre's work flow. Thinking about it a bit more
I think I've come up with a solution to the problem that should not
disrupt Alexandre's flow if I understand git properly. Let me preface
this with saying that I don't.

At first I thought we might be able to use the sha1 hashes that are
the patch names themselves to track if a commit had be accepted or
not, but then I guess that would only work if we were pushing and
pulling directly in to each others tree's as I see the commit hash
differs from the patch hash in the patches I've reviewed. I can only
assume this is because of the way git views looks at the entire repo
as one chunk of data rather than dealing with single patches.

Then as I dug in to it a bit more I noticed the index's did match
provided Alexandre did not make any changes before he committed. I was
thinking this could be a use for a tracking system.

Lets imagine there is this patch daemon that sits out there and reads
wine-patches, storing the diff and parsing the index in to a database.
This deamon could do a git fetch every 30 mins or so to compare and
see if a patch has been merged in based on the index. It seems like we
already have most of the tools we need to do it now if someone really
wants the tracking system. We know about the patches and we know if
its been merged or not, defining rules for accepted or rejected seem
pretty trivial to me as we already have the rule, if its not merged in
a week then resend.

So here is what it would look like as far as work flow goes, someone
submits a patch, it goes to this database and up to a website with a
listview showing all the patches. Anything not merged yet still in the
two week window would show up in the list as white meaning still
pending.

The further up the list we would have patches that were merged and
accepted as is, like the following (showing up in green)
http://www.winehq.org/pipermail/wine-patches/2008-February/049719.html
http://source.winehq.org/git/wine.git/?a=commit;h=ac61b90f87a2062b99f6f70686ea86b5b6c241c3

The following patch would show up in yellow as the index differs for
the Makefile part of the patch as Julliard made local changes
http://www.winehq.org/pipermail/wine-patches/2008-February/049720.html
http://source.winehq.org/git/wine.git/?a=commit;h=5bad12c6bc3072a2676f0d9edc9e3a48bca1ceaf

Any other patches that don't get merged would show up in the list as
red after the one week window went by. The tracker would assume they
were rejected.

The cool thing about this is that we could directly link it in to
bugzilla so that when a patch is applied the bug could get
automatically updated.

Now this all hinges on being able to use the diff index to do the
tracking. I imagine there might be conflicts if your trying to use
that as the only data point as its not as long as a real hash, but
assuming your only doing a compare over as period of a few weeks or a
month I think it would work. Am I wack? Is there even still the desire
to have a graphical patch tracking system?

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo



More information about the wine-devel mailing list