Hello, if you look at http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html you'll see there was a project at some point to make a decent patch management system, but apparently due to the complexity of it and Newman being constantly overloaded with work, it never got anywhere, do you guys think it's doable/would you be willing to volunteer to build something of the sort? It would make wine development easier quicker (No more wondering "should I ask Alexandre about that patch? Is it too soon? should I wait a little longer? should I rewrite it? to be or not to be?") and would be great value for the project as it would probably make it easier for new developers to join. Ivan.
On Thu, 8 Sep 2005, Ivan Leo Puoti wrote:
Hello, if you look at http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html you'll see there was a project at some point to make a decent patch management system
What is a 'patch management system'? If it's something Alexandre uses to apply patches, then his requirement that it be usable from his desktop environement (Emacs) precludes a web-based system. So what about something more like a patch tracking system, not for Alexandre's use but for everyone to see on the web? The idea would be to match emails sent to wine-patches with commits made to CVS as found in the wine-cvs mailing list for instance. Then each email would be in one of the following states: * pending New emails that have just been sent. * committed We found a CVS commit that matches this email. We could link such emails to the corresponding commit. * dropped After 48 hours in the pending state, emails go into the dropped state. The system could even automatically send an email to the submitter explaining the situation and pointing to a web page describing what to do. We could arrange to send that email only to new contributors by keeping a list of email addresses which have received one already. Obviously the 48 hours delay should be adjusted for week-ends and Alexandre's vacations. * discuss Emails that have not been committed and for which we find a reply either in wine-patches or in wine-devel go into this state. In particular this means they never enter the dropped state. Basically the idea is that if someone replied to the email it's either to point out the patch is missing, wrong, incomplete or some such and thus we should have no expectation of the patch being committed. But if we then find a match in wine-cvs then fine, switch it to committed. * hidden The system would hide replies to other wine-patches emails. There would most likely be some miscategorisations but as long as it's not too many of them it does not matter. The benefits would be: * we'd have a clear indication of what's the status of a patch * we'd have a better idea of how many patches get dropped * if we implement the automatic email notification submitters of dropped patches would automatically get instructions on how to remedy the issue * dropped patches would be clearly visible making it easy for volunteers to investigate them and take action How can we match wine-patches emails to CVS commits? * date If the commit was before the patch was received by wine-patches then it does not match * submitter name / email Alexandre always puts the submitter name / email on the first commit line so we can check for a match or partial match (name or email only) there. * commit log This one is tricky because we are unlikely to get a perfect match. Still the commit log should be present somewhere in the email, either in the subject or in the body. In some cases it could be in the attachement and if we can scan attachements that's good, but I think this case is not frequent enough to matter if we cannot. * modified files If we can open attachements and parse the diff then we could compare the list of files in the diff and in the commit. But I don't think this is needed for proper matching. Note that one commit may correspond to more than one wine-patches email (resends). So loop on the emails and try to find matching cvs commits. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Francois Gouget wrote:
On Thu, 8 Sep 2005, Ivan Leo Puoti wrote:
What is a 'patch management system'?
If it's something Alexandre uses to apply patches, then his requirement that it be usable from his desktop environement (Emacs) precludes a web-based system.
So what about something more like a patch tracking system, not for Alexandre's use but for everyone to see on the web?
We don't need that, it's not much better than what we've got and isn't worth the effort, what is needed is something that Alexandre can use. New patches are "New", committed patched are "committed" and rejected patches are marked as "rejected, reason:" so people can know what is and isn't committed and why as soon as Alexandre makes that decision. Cool additional features could including optionally sending an email with updates about the patch status to the author. So this would require some sort of back end database, something that Alexandre can use (And it's crazy that Emacs doesn't have web support, that means Alexandre can't use the web), and a web based interface for patch submitters. Maybe Jeremy could tell us what the precise idea was before it was dropped from Newman's todo list. Ivan.
On Thu, 8 Sep 2005, Ivan Leo Puoti wrote:
Francois Gouget wrote:
On Thu, 8 Sep 2005, Ivan Leo Puoti wrote:
What is a 'patch management system'?
If it's something Alexandre uses to apply patches, then his requirement that it be usable from his desktop environement (Emacs) precludes a web-based system.
So what about something more like a patch tracking system, not for Alexandre's use but for everyone to see on the web?
We don't need that, it's not much better than what we've got
I disagree. It would be loads better than what we have now (i.e. nothing):
The benefits would be: * we'd have a clear indication of what's the status of a patch * we'd have a better idea of how many patches get dropped * if we implement the automatic email notification submitters of dropped patches would automatically get instructions on how to remedy the issue * dropped patches would be clearly visible making it easy for volunteers to investigate themand take action
Also it would not require disrupting Alexandre's routine or having him do extra work. And the optional email to new submitters would be much more friendly than having the patch go into a black hole without the drawback of bothering old-time contributors. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.
Francois Gouget wrote:
Also it would not require disrupting Alexandre's routine or having him do extra work. And the optional email to new submitters would be much more friendly than having the patch go into a black hole without the drawback of bothering old-time contributors.
I'm still in favour of a real patch management system, if it was on Newman's todo list it can't be an evil idea and I think it would really help new and old developers. Ivan.
On 9/8/05, Ivan Leo Puoti <ivanleo(a)gmail.com> wrote:
We don't need that, it's not much better than what we've got and isn't worth the effort, what is needed is something that Alexandre can use. New patches are "New", committed patched are "committed" and rejected patches are marked as "rejected, reason:" so people can know what is and isn't committed and why as soon as Alexandre makes that decision.
All of this comes down to one simple thing... "Communication Overhead" And the way I see it AJ would soon go from hacking and committing patches to explaining why every dropped patch was dropped. So the question at the end of the day comes down to this, do we want AJ working on hacking/committing or sending reasons why patches dont get applied? There are only 24 hours in a day and I believe the current system is the most productive. 1) send a patch 2) wait five days for a commit 3) re-submit after five days has passed 4) if the patch still isn't committed after two days ask why. This gives everyone who is interested a week to review/test the patch in question. Tom
Ivan.
On 9/8/05, Tom Wickline <twickline(a)gmail.com> wrote:
1) send a patch 2) wait five days for a commit 3) re-submit after five days has passed 4) if the patch still isn't committed after two days ask why.
7 days is a long time to wait for an explanation of why a patch wasn't committed. I usually wait a day, resubmit the patch asking why it wasn't accepted. One of the biggest problems we have is one of responsibility. It's easy to become dependent on Alexandre to tell us why each of our patches is not acceptable (I'm guilty of this too). More responsibility should be shifted from Alexandre to the developers when it comes to examining submitted patches. If a patch is not accepted, the developer that sent the patch in (and even other developers) should review the patch and try to see what is wrong with it. Put yourself in Alexandre's shoes and think why he would reject it. Granted it isn't always possible to know why a patch was rejected (design issue maybe), but if more time was spent reviewing our own patches (before and after submission), I don't think this would be as big of an issue. You have to keep in mind that Alexandre has a lot more work to do then reviewing and committing patches, and it isn't his job to make our patches correct. -- James Hawkins
On 9/8/05, James Hawkins <truiken(a)gmail.com> wrote:
On 9/8/05, Tom Wickline <twickline(a)gmail.com> wrote:
1) send a patch 2) wait five days for a commit 3) re-submit after five days has passed 4) if the patch still isn't committed after two days ask why.
7 days is a long time to wait for an explanation of why a patch wasn't committed.
The only reason why I said 7 days was you need to take week ends, days off, holidays, your position in the Que and so on into account. So maybe seven days is a bit long but I'm sure if someone here said two days someone would scream if two days went by and there patch wasn't committed when it might have been on the third.. I agree with the other commits you made. Tom
-- James Hawkins
On Thu, 8 Sep 2005 23:06, Francois Gouget wrote:
If it's something Alexandre uses to apply patches, then his requirement that it be usable from his desktop environement (Emacs) precludes a web-based system.
Not really. A web based system could provide an alternative interface that allows for other front-ends (an XML interface for buzzword compliance). This would facilitate a split in development to that you don't need somebody who knows both PHP and elisp to develop it - get one who knows PHP and one who knows elisp. It would also lay the groundwork for having a variety of front-ends. More importantly, it would provide an opportunity for integration with bugzilla, and submission of patches via a web interface is likely to result in better consistency, specifically dealing with the following problems: 1. Submit the patch as a file through the web and you get the same result every time, submit it through email and everybody's mail client might do something slightly different and wrong, multiplied by configuration differences and PEBCAKs); 2. A web submission system could insist on a ChangeLog and possibly some additional explanatory text (why the change is needed, why it was done a particular way); 3. A web submission system could effectively provide for other niceties such as recording patch dependencies and when a newer patch supercedes an older one. You would have four phases: 1. Define the functionality required; 2. Implement functionality with web-based interface (probably in PHP since that's what's used for the appdb and so what the appdb coders are familiar with); 3. Implement an XML option for the functions that make sense inside an IDE (and I suppose you could call emacs the original IDE); and 4. Implement the emacs frontend for that interface. At the moment we're really only at (1) though. The broad basic requirements are: 1. Can receive patches via the web and/or wine-patches; 2. Provides an interface allowing for application of patches and changing the state of the patch, and whatever else Alexandre does; 3. Provides notification to the patch submitter whenever the state changes. Other niceties would include: 4. Gateways web submissions back to wine-patches; 5. Tracks discussion of a particular patch; 6. Ability to assign a patch to somebody else to review; 7. Ability to determine who has primary responsibility for a patch based on the files modified by the patch (so that if there are different committers for particular areas, then only the appropriate one needs to deal with the patch).
participants (5)
-
Francois Gouget -
Ivan Leo Puoti -
James Hawkins -
Tom Wickline -
Troy Rollo