Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: Actually, that's not how I intended things to work. The automatic removal from the queue would only happen if the patch had a RFC status, i.e. if action is expected from the patch submitter. If the patch is unopposed and just waiting in the queue, it should stay there. It's reasonable to tell a submitter you seem to have lost interest in this patch, it has been waiting on action from you for [a month, whatever] but nothing has happened, therefore it will be removed from the queue. Sending a warning message your patch is going to be dropped without explanation is no improvement over the current situation. Ok, I misunderstood. These things are tricky to comprehend and even harder to discuss. :) // Jakob
Re: Patchwork (was Re: Governance revisited)
Mike McCormack wrote: Ge van Geldorp wrote: My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. I have been watching this thread with keen interest. Alexandre does not HAVE to respond to that patch, he can silently ignore it just like he can now. The only difference with Patchwork would be that after a certain time with no comments and no commits, the patch would be removed from the queue and the submitter would get an email warning. regards, Jakob Eriksson
Re: Patchwork (was Re: Governance revisited)
From: Vitaliy Margolen [EMAIL PROTECTED] So in a sense you will require some one to respond for any incoming e-mail to wine-patches. And if no one does, Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. What if he already applied the patch? Now you slowing down what would have worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. Ok now you making it dependant on an e-mail client. Yet that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. Not really. You can't make some one to review something that don't understand. Or if they are busy/on vacation/away from PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. So in the end you'll end up with either huge queue that no one wants to touch. Or a clean up jobs that will once in a while go and mark all patches as old and will require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html When people well send out right hacks and expect some one to tell then what they really should do. Current system allows to no waste any time on such craft. We seem to have fundamentally different views of the peripheral (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. No, by requiring some one to respond you making them responsible (at least until they respond). Of course responses like sucks wouldn't be nice, so some one who does understand the subject will have to spend their time to understand the patch, write a review of the patch and send it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? And you want that ASAP! Which means whenever patch arrives in wine-patches some one (most likely more then one person) will stop everything they are doing, and start writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp ge at gse.nl writes: From: Vitaliy Margolen wine-devel at kievinfo.com So in a sense you will require some one to respond for any incoming e-mail to wine-patches. And if no one does, Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. Hi, Just to mix in this discussion my 0.02, I am one of those would-be submitters who hasn't done so because I don't want to submit crappy code. I've been viewing at loads of patches to see what they need to conform to. In my opinion, this patchwork system combined with the proposal of mentors/domain experts (as also described by someone in this thread) would mean that once I submit a patch which does not comply with the rules (which I would not know as starting contributer), I at least would get a message back from the bot which tells me why it was obvious wrong. Perhaps based on this I would receive a link to a wiki page where these rules are mentioned? If the mentors get multiple patches from different patches with a generic mistake, perhaps a new rule could be added to the bot (and the wiki) to prevent new contributers from making this mistake in the future. Worst case scenario: The bot does not find anything wrong, the mentor would review and approve, but Alexandre would not approve. In this case at least it would be rejected and he would have to make a (minor) comment as to why. But this seems to be the current situation. For me, the positive side would be that I could have an overview of my patches, learn from the feedback and improve them. I'm not saying that that is currently not possible, but since I am only able to work on this after working hours, it would take more of a bite out of my time available than if this patchwork system would be there, which increases the chances of me actually submitting patches. There is a lot of information for developers in the wiki already, but as a new person it would be nice to have some tools/pages to guide you through the process. I am very much in favour of the mentor initiative, since they could filter/improve the patches for specific areas before Alexandre needs to be bothered and provide valuable feedback to me. Okay, system or not, I will continue to try to contribute. Even if it is just by testing applications or translating strings. Frans Kool.
Re: Patchwork (was Re: Governance revisited)
On Thursday 28 September 2006 05:49, Mike McCormack wrote: Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. He still has to take an action to review each patch now, and presumably some action to remove it from his queue (speculation since we don't have his process documented - which is why I asked if we could get a vncrec file showing a patch reveiew/application/rejection session, so I could document it). If the process fits into this workflow without disruption the cost should actually be less since it saves having a conversation about why the patch was rejected. It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. You seem to be assuming people are submitting patches they *know* will not be accepted (discounting ones submitted for the purposes of record only where the submitter says they don't expect it to be committed). This would be pathological behaviour since it would require more work on the part of the submitter as well as on the part of Alexandre. In fact the present process is likely to involve more work since it requires people to speculate about why the patch was rejected or passed over, and if they get it wrong, resubmit. Often there wasn't even anything wrong in the first place (the oops bitbucket) so all the speculation and rework will be a pointless exercise. If the patch is reworked, it's submitted again, has to be reviewed again, wait, rinse, repeat. That will result in more patches than if people are told the actual (rather than speculative) reason it was not applied. The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. (the following sounds somewhat harsher than it's intended to but I couldn't figure out a better way to say it) If you can call speculation thinking, but I don't know what you mean by scales better. Speculative review increases the chance that Alexandre has to spend time reviewing more wrong patches because other people guessed wrong. The current system has literally cost me tens of thousands of dollars in wasted developer time on just a handful of patches (not including time I have wasted on it personally), so if by scales better you mean passes off a relatively small cost off (sometimes without actually removing that cost) to others magnified by huge factors then yes I guess it does scale better, but scaling up the expense doesn't seem to be a good idea to me. Maybe some other employers don't mind throwing money away like this (Jeremy?), but I do. Responding to each and every patch seems like it would be a waste of Alexandre's time. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. It's more of an heuristic than a determinitive process unless the reviewers know for certain Alexandre's reasons for rejecting a patch (assuming an unapplied patch has in fact been rejected), which requires either telepathy or that he tell them. The current process results in regular oops situations leading to no feedback. There are the oops, must have missed that patch, and oops, I thought I did reply to tell you what was wrong with that patch, both of which I have seen multiple times. These at least could be improved with a suitable system in place and result in some improvement even if the speculative post-rejection-review process is kept. I'm not sure why you seem to be opposed to even attempting to find a better process that will work for everybody. The attempt to do so may well fail, but the surest way to fail is not to try. -- [EMAIL PROTECTED] - Sydney, Australia pgpK8AHMzEWjY.pgp Description: PGP signature
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. From your other mail: mention the time it costs the author. Shouldn't we be looking at the productivity of everyone involved in Wine development and not just at Alexandres productivity (although I acknowledge his special position)? I'm a bit surprised (and, to be honest, also a little bit annoyed) about the low value you seem to place on the time contributed by the developers. With a single maintainer system, costs to patch submitters and authors are much less crucial to a working system than costs to the single maintainer. Spreading the workload, so the many do more work, is the only way to improve the system. We agree that encouraging more reviewers is a good thing, so how about focusing on ways to get more people to review patches? Mike
RE: Patchwork (was Re: Governance revisited)
Hello Mike, From: Mike McCormack [mailto:[EMAIL PROTECTED] That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. Unless you can read Alexandres mind, he's really the only one who can tell what he didn't like about a certain patch. Hopefully he'll get help from others to weed out obviously incorrect patches, but in the end it's his decision. With a single maintainer system, costs to patch submitters and authors are much less crucial to a working system than costs to the single maintainer. Which is why I made the remark about Alexandres special position. It doesn't mean (at least I hope it doesn't mean) that costs to authors are not important at all. We agree that encouraging more reviewers is a good thing, so how about focusing on ways to get more people to review patches? One doesn't preclude the other. I indeed agree it would be good to get more people to review patches, but I also think that's not a complete solution. The results of the review (either by peers, subsystem maintainers or Alexandre) needs to be communicated back to the author. Focusing solely on review doesn't solve the problem of patches getting lost either. Ge van Geldorp.
RE: Patchwork (was Re: Governance revisited)
From: Jakob Eriksson [mailto:[EMAIL PROTECTED] I have been watching this thread with keen interest. Alexandre does not HAVE to respond to that patch, he can silently ignore it just like he can now. The only difference with Patchwork would be that after a certain time with no comments and no commits, the patch would be removed from the queue and the submitter would get an email warning. Actually, that's not how I intended things to work. The automatic removal from the queue would only happen if the patch had a RFC status, i.e. if action is expected from the patch submitter. If the patch is unopposed and just waiting in the queue, it should stay there. It's reasonable to tell a submitter you seem to have lost interest in this patch, it has been waiting on action from you for [a month, whatever] but nothing has happened, therefore it will be removed from the queue. Sending a warning message your patch is going to be dropped without explanation is no improvement over the current situation. Gé van Geldorp.
Re: Patchwork (was Re: Governance revisited)
From: Alexandre Julliard [EMAIL PROTECTED] If you expect anything to happen, you'll need to make much more concrete suggestions, and provide examples to make us understand how what you are suggesting would work in practice Fair enough. Some disclaimers upfront: I'm basically thinking out loud, I have no idea what your typical workflow looks like. I'm also not restrained by any knowledge of emacs and what can be done in its plugins, macro's, user-defined commands or whatever they're called. But I know I could code the proposal below in e.g Perl or C, so I guess it should be possible in Lisp also. Who's going to code that is a different matter altogether, let's first see if we can think of a solution which would work. Let's assume a patch is submitted to wine-patches. A bot would receive it and store it in a database (Patchwork already seems to do a fine job on this). The bot could do some simple checks, like does it apply cleanly, no C++ comments, whatever automatic checks we can come up with. If one of the checks fails, the status would be set to RFC (Request For Change, I'm using the Patchwork statuses here) and the author would receive an automatic email explaining what's wrong, otherwise the status would be set to New. Note that this should save you some time, weeding out obviously wrong patches. On to your workflow. You'd issue a Meta-Ctrl-Shift-whatever emacs command. Behind the scenes, this would send a request to the webserver which would reply with a list of queued patches. This list could be sorted by a score. Authors who consistently submit good patches would get a higher score than, well, me. This score could be computed as the number of accepted patches minus the number of rejected patches. A patch already reviewed (and recommended) by a subsystem maintainer could get a real big score boost so it ends up near the top of the list. Patches which have been in the queue for a few days could get extra points. Patches with RFC status wouldn't be shown at all or get a very low score. Anyway, you end up with a list of patches on your screen with the least problematic near the top. This should help ensure that these get through pretty quickly. So you select a patch which is then retrieved from the server. It could be automatically applied, a build started, whatever suits you best. Comments made on it by other developers could be shown to you. After testing is complete, you issue a decision command. You can decide to accept the patch, that would send an accept message to the webserver and perhaps it could be comitted to your git repo. If the patch needs more work, you'll be prompted for a message. That message will be mailed to the author with a copy to win-devel and it will be sent to the webserver which will change the patch status to RFC. If you think the patch is beyond hope it can be rejected outright (again with a message to author and wine-devel). Or you can decide not to decide on it today and sleep on it for a night. Then the patch will just show up in the list of pending patches again tomorrow, with a little bit higher priority (since it has been in the queue longer). Back to the list of pending patches, repeat. and how it would be different from what we are doing now. It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Ge van Geldorp.
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: It would make sure the author always receives some kind of feedback (either from the bot, other developers or yourself) and would make sure patches don't get lost (patches are automatically entered into the system and only leave the system when the author withdraws them or when you make a final decision). Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. Responding to each and every patch seems like it would be a waste of Alexandre's time. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. btw. Is there any reason that you can't request a review of your patches, or report the problem that you're trying to fix in bugzilla, as I suggested elsewhere? Mike
Re: Patchwork (was Re: Governance revisited)
On 9/27/06, Mike McCormack [EMAIL PROTECTED] wrote: Responding to each and every patch seems like it would be a waste of Alexandre's time. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. +1 -- James Hawkins
RE: Patchwork (was Re: Governance revisited)
From: Mike McCormack [mailto:[EMAIL PROTECTED] Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. No, it doesn't require that. It requires *someone* to respond, that could be a fellow developer on wine-devel. A comment added via the web interface or a message about the patch on wine-devel would set the status to RFC, meaning the patch wouldn't show up in Alexandres list (or with a very low priority). It would be the responsibility of the author to set the status back to New if he thinks that's appropriate. Sorry if that wasn't clear from the message you replied to, that message was explicitly aimed at the work Alexandre does, there's more to the system than just that. For the automatic status update to work, we would need to make an automatic connection between wine-devel messages and the patch, could be done using the In-Reply-To header or making sure each message sent out on wine-patches has a unique ID in its subject, a reply to that message would (in most email clients) copy the subject including the unique ID. In the end, when the number of developers grows, the number of reviewers grows too (every developer is a potential reviewer). Seems to scale pretty well actually. It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. First of all, I don't see the encouragement and secondly, how does the current system prevent that? The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. I'm not sure why you think responsibility for the patch would shift. It would still be the authors responsibility to write acceptable code. The only thing that would change is that the author gets feedback at the earliest possible moment, be it from the bot, peer review or Alexandre. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. Absolutely. The proposed system doesn't change the review process, it allows peer review too. It just acts as a kind of safety net. Authority and responsibility should go hand-in-hand. I hope it's clear that I don't have a problem with Alexandre having the authority to make the final decision on whether a patch goes in or not, I just believe that with that authority comes the responsibility to inform the author if a patch isn't acceptable in it's current form. Hopefully a fellow developer has already reviewed the patch and told the author something is wrong but in the end we as developers are not psychic and simply cannot know what Alexandre thinks about a patch. btw. Is there any reason that you can't request a review of your patches, or report the problem that you're trying to fix in bugzilla, as I suggested elsewhere? How would that improve Alexandres productivity? As pointed out by Troy, it just means he has to look at a patch twice before sending a reply. Not to mention the time it costs the author. Shouldn't we be looking at the productivity of everyone involved in Wine development and not just at Alexandres productivity (although I acknowledge his special position)? I'm a bit surprised (and, to be honest, also a little bit annoyed) about the low value you seem to place on the time contributed by the developers. Ge van Geldorp.
Re: Patchwork (was Re: Governance revisited)
On Thursday 28 September 2006 05:49, Mike McCormack wrote: Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. He still has to take an action to review each patch now, and presumably some action to remove it from his queue (speculation since we don't have his process documented - which is why I asked if we could get a vncrec file showing a patch reveiew/application/rejection session, so I could document it). If the process fits into this workflow without disruption the cost should actually be less since it saves having a conversation about why the patch was rejected. It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. You seem to be assuming people are submitting patches they *know* will not be accepted (discounting ones submitted for the purposes of record only where the submitter says they don't expect it to be committed). This would be pathological behaviour since it would require more work on the part of the submitter as well as on the part of Alexandre. In fact the present process is likely to involve more work since it requires people to speculate about why the patch was rejected or passed over, and if they get it wrong, resubmit. Often there wasn't even anything wrong in the first place (the oops bitbucket) so all the speculation and rework will be a pointless exercise. If the patch is reworked, it's submitted again, has to be reviewed again, wait, rinse, repeat. That will result in more patches than if people are told the actual (rather than speculative) reason it was not applied. The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. (the following sounds somewhat harsher than it's intended to but I couldn't figure out a better way to say it) If you can call speculation thinking, but I don't know what you mean by scales better. Speculative review increases the chance that Alexandre has to spend time reviewing more wrong patches because other people guessed wrong. The current system has literally cost me tens of thousands of dollars in wasted developer time on just a handful of patches (not including time I have wasted on it personally), so if by scales better you mean passes off a relatively small cost off (sometimes without actually removing that cost) to others magnified by huge factors then yes I guess it does scale better, but scaling up the expense doesn't seem to be a good idea to me. Maybe some other employers don't mind throwing money away like this (Jeremy?), but I do. Responding to each and every patch seems like it would be a waste of Alexandre's time. We should encourage more people to participate in the patch review process, so that we have more reviewers and a more scalable process. It's more of an heuristic than a determinitive process unless the reviewers know for certain Alexandre's reasons for rejecting a patch (assuming an unapplied patch has in fact been rejected), which requires either telepathy or that he tell them. The current process results in regular oops situations leading to no feedback. There are the oops, must have missed that patch, and oops, I thought I did reply to tell you what was wrong with that patch, both of which I have seen multiple times. These at least could be improved with a suitable system in place and result in some improvement even if the speculative post-rejection-review process is kept. I'm not sure why you seem to be opposed to even attempting to find a better process that will work for everybody. The attempt to do so may well fail, but the surest way to fail is not to try. -- [EMAIL PROTECTED] - Sydney, Australia
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: From: Mike McCormack [mailto:[EMAIL PROTECTED] Seems like that is a system that doesn't scale well at all, as it requires Alexandre to specifically respond to each and every patch. No, it doesn't require that. It requires *someone* to respond, that could be a fellow developer on wine-devel. A comment added via the web interface or a So in a sense you will require some one to respond for any incoming e-mail to wine-patches. And if no one does, Alexandre don't get to see the status? What if he already applied the patch? Now you slowing down what would have worked just fine before. For the automatic status update to work, we would need to make an automatic connection between wine-devel messages and the patch, could be done using the In-Reply-To header or making sure each message sent out on wine-patches has a unique ID in its subject, a reply to that message would (in most email clients) copy the subject including the unique ID. Ok now you making it dependant on an e-mail client. Yet that's exactly what we are trying avoid with GIT. In the end, when the number of developers grows, the number of reviewers grows too (every developer is a potential reviewer). Seems to scale pretty well actually. Not really. You can't make some one to review something that don't understand. Or if they are busy/on vacation/away from PC/etc. So in the end you'll end up with either huge queue that no one wants to touch. Or a clean up jobs that will once in a while go and mark all patches as old and will require authors to resubmit. How's that better then what we use now? It also seems like it encourages patch submitters to not polish their patches themselves and just submit a higher volume of low quality patches for Alexandre to review, since the onus will then be on him to respond. First of all, I don't see the encouragement and secondly, how does the current system prevent that? When people well send out right hacks and expect some one to tell then what they really should do. Current system allows to no waste any time on such craft. The current system, which leaves the responsibility for the patch with the submitter both scales better, and encourages patch submitters to think about their patches more. I'm not sure why you think responsibility for the patch would shift. It would still be the authors responsibility to write acceptable code. The only thing that would change is that the author gets feedback at the earliest possible moment, be it from the bot, peer review or Alexandre. No, by requiring some one to respond you making them responsible (at least until they respond). Of course responses like sucks wouldn't be nice, so some one who does understand the subject will have to spend their time to understand the patch, write a review of the patch and send it. And you want that ASAP! Which means whenever patch arrives in wine-patches some one (most likely more then one person) will stop everything they are doing, and start writing a review? Vitaliy
Patchwork (was Re: Governance revisited)
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. It ought to go without saying that a patch management system should make things *easier* for maintainers rather than harder(*). Ideally it should be easier to take a step using the patch management system that it is to take the same step without it. If there are places where taking the same step is harder or more time consuming in the patch management system, it should at least provide a clear down-the-track benefit to the maintainer to make it worth it to the maintainer to take that extra time. The Patchwork maintainer is interested in improving it - particularly in ways that will make maintainers want to use it - so given that there is at least the beginnings of a project out there aimed at meeting the general requirements it makes some sense to put some effort into it. Step 1 has to be to get a few members of that particular target group to document the procedures they go through to get a patch from the mailing list through to git and/or to some other state. 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? (*) it should also make things easier for contributors, but maintainers are the critical pressure-point. -- Troy Rollo - [EMAIL PROTECTED]
Re: Patchwork (was Re: Governance revisited)
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
Re: Patchwork (was Re: Governance revisited)
I didn't respond to Alexandre's point earlier, but wanted to now: 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. Hmm. I suppose you (and others) could CC the patch-daemon on any reply, which could have a similar effect. Misses objective #1 of you not having to change anything, but, in theory, keeps the basic mechanism intact. Cheers, Jeremy
Re: Patchwork (was Re: Governance revisited)
Accepted patches will appear in the wine-cvs mailing list. Patches with obvious problems may receive a response on wine-devel. Some patches may not receive any response. In this case, your patch maybe considered 'Not Obviously Correct', and you can: * check the patch over yourself, and think about what can be done to clarify the patch (hints in the list above) * write a mail to wine-devel, explain your patch and request it be reviewed by anybody that cares to review it * unless one already exists, open a bug in bugzilla describing the problem you are trying to solve (eg. ./configure fails on Solaris, etc) and attach your patch. * ask for advice about your patch on #winehackers You may find it difficult to solicit feedback, so think carefully about the comments you receive. Jeremy White wrote: 2. Other wine-hackers can see what patches are apparently headed through cracks, and get a chance to jump on them. The proactive approach of the patch submitter requesting a review on wine-devel seems better to me. There's more chance people will respond to a mail with a summary of the issue than that they'll monitor a web page. Instead of spending time building a patch tracking system, I propose that we modify the submitting patches page as below. Mike -- Accepted patches will appear in the wine-cvs mailing list. Patches with obvious problems may receive a response on wine-devel. Some patches may not receive any response. In this case, your patch maybe considered 'Not Obviously Correct', and you can: * check the patch over yourself, and think about what can be done to clarify the patch (hints in the list above) * write a test case showing your patch is correct * write a mail to wine-devel, explain your patch and request it be reviewed by anybody that cares to review it * unless one already exists, open a bug in bugzilla describing the problem you are trying to solve (eg. ./configure fails on Solaris, etc) and attach your patch. * ask for advice about your patch on #winehackers You may find it difficult to solicit feedback, so think carefully about the comments you receive.
Re: Patchwork (was Re: Governance revisited)
On Tuesday 26 September 2006 22:55, Jeremy White wrote: 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. This (and point 2) is similar to what the Patchwork author is thinking of doing anyway. I was hoping to achieve something a little more than that by providing something that might actually streamline Alexandre's processes and so make it attractive to move to. What might be good is if we could get a vncrec http://www.sodan.org/~penny/vncrec/ file showing a typical patch review and application session. If we could get one within the next 24 hours, I could take it away and document the process by Tuesday, together with indicating any areas where the process could be improved by a new system. 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. However one principle should be that to the maximum extent possible, the system should *trigger* a reaction rather than just hoping somebody takes an action. But I should point out I'm not rushing to volunteer to write the daemon or revise Patchwork or actually do any useful work... It's in Perl anyway, best left to Perl hackers. Other people tend to go insane working on Perl code, and then they *become* Perl hackers. (On the other hand it's fairly small now so a rewrite in some other language is feasible if necessary).
