Troy Rollo wrote: > As I speculated, the reason the PPC64 Patchwork example was so out of date > was > that the PPC64 list had been folded into the vanilla PPC list, however the > big problem right now is that Patchwork is "extra work" for maintainers, so > right now they don't want to use it.
Ouch. This is what I fear. > Jeremy - do you have any documentation for this from the last time you looked > at implementing patch managemen, and if so is it up to date for Git? Well, despite my doubts of the usefulness of this, I remain quite interested in trying to improve the process. I should warn you, though, I'm famous within CodeWeavers for having 'Clever Ideas That No One Uses' (TM). I fear that a patch tracker is just one such. But here is a private thread between myself and Alexandre, in which I noodled on a possible approach, and in which Alexandre shot me down <grin>. ------------------- Okay, so here's is my next Clever Idea That Isn't Used (CITIU): Assumptions: 1. We can write a utility that lets us compare a winehq commit message to a wine-patches email and see if there is a 'match'. 100% isn't required, but some nice non zero number is. A key requirement is that there are near zero false hits. 2. We can write a utility that lets us look at an email on wine-devel and see if it is a reply to a patch on wine-patches. Again, the assumption is that 100% match isn't needed. For this one, though, we should be able to do much better (as we'll have a message id usually). We also can tolerate very few false hits here as well. Tasklist: 1. Build a process that receives email from wine-patches, wine-devel, and wine-cvs. Each new email to wine-patches goes into a database. 2. Each email from wine-cvs looks for a patch in the db, and deletes a matching patch. (Or perhaps sets status to 'committed'). 3. Each email from wine-devel looks for a matching patch in the db, and if there is a hit in the db, we delete it as well. (Or perhaps set status to 'replied'). 4. We write a web page that displays all patches in the db, with some nice filters. It has a button to allow someone to change a patch status (that way, we can clean up for the cases where a human being can see that there was a match, but the process couldn't). Hoped for Result: 1. You do nothing new. 2. Other wine-hackers can see what patches are apparently headed through cracks, and get a chance to jump on them. 3. People who submitted a patch have a page to see the status, and get a clue as to what might have happened to it. Possible futures: 1. We could give you a 'urk!' button somewhere that would actively flag a patch as something you'd appreciate someone else think about; that could raise them up. If we do this as a daemon, we could probably even do it trivially as a reply-to [EMAIL PROTECTED] right out of emacs. (We can get even fancier here; the sky is the limit, but I fear too much cleverness). Issues I see: 1. Yet Another Clever But Unused Idea 2. Private emails are unaccounted for. Are they a major factor? 3. Haven't proven our assumptions yet ----------------- To the private email issues, Alexandre replied: There are a fair number of such cases, yes. Not so much the bad patches but the corrupted/mangled/doesn't apply patches; I don't want to fill wine-devel with "this patch is corrupted please resend". And I know other people often reply in private too, for instance when someone forgot the attachment. Also there are a lot of cases where a patch won't get committed but shouldn't be in the list, people often supersede their own patches, or two people fix the same thing in two different ways, etc. So I feel it would require active monitoring to keep the list somewhat up to date, and I don't know that there would be people willing to do that in the long run. ---------------- I guess it's the latter point that is key. We can automate some of this, but in the end, some human monitoring will be required. Being a foolish optimist, I don't see any harm in trying, particularly if we focus on benefit #1 (Alexandre doesn't have to do anything :-/). But I should point out I'm not rushing to volunteer to write the daemon or revise Patchwork or actually do any useful work... Cheers, Jeremy