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=ac61b90f87a2062b99f6f70686...
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=5bad12c6bc3072a2676f0d9edc...
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?
On Friday 08 February 2008 08:51:15 Steven Edwards wrote:
I'll skip the technical discussion and go right to the beef.
Is there even still the desire to have a graphical patch tracking system?
Personally I tend to use feature branches in git that I rebase on the top of Alexandre's tree. Simply starting gitk will show me which of my patches have been accepted and which of them are still on top of the tree. Of course that means I need to track which of those I sent.
Using more branches, this is even more clear.
Assume you have two git branches, 'submitted' and 'my-cool-feature'
You develop in 'my-cool-feature'. Once a patch is ready to be committed, you git-cherry-pick it to the 'submitted' branch, git-format-patch | git-imap-send or whatever you do to send it to wine-patches. Now you can keep track of your submitted patches easily.
A web interface can be nice, so if anyone feels like hacking this up I'm definitely not going to stop them. All I want to say is that I think it's not needed for personal use.
Cheers, Kai
-
Kai Blin -
Steven Edwards