Hi, Dmitry Timoshkov wrote:
How many projects have you ever participated in? Every developers' mailing list of an open source I personally participated in *doesn't guarantee* not only patch acceptance, but even a reply with explanations why the patch has been silently dropped, and it doesn't matter how many maintainers a project has. Why do you request that from Wine, and particularly from Alexandre?
Alexandre is not a robot, he is a human. Please take that into account.
Sounds like he need more help.
It's a metter of the fact, that if you can't cope with other people's requirements, you can't work in a team.
Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine .
It is your job to provide support for this product, I spend money and I need help, where do I go?
Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list?
This project needs a course in technical sales support. Good idea for the next WineConf!
Remember you represent CodeWeavers, start acting like it. 8^D, James
On 9/25/06, jimtabor jimtabor@users.sourceforge.net wrote:
Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine .
I'm a Wine developer, and I don't work for codeweavers. Why should I read that?
It is your job to provide support for this product, I spend money and I need help, where do I go?
It is not my job to provide support for this product. Even if you're referring to Dmitry and everyone else that works at Codeweavers, you're still wrong. This is the wine-devel mailing list, and has nothing to do with Codeweavers. You confuse Crossover Office and Wine as being the same product/project. Just because they work at Codeweavers, can they not also work on Wine and not have affiliation with Codeweavers? Of course they can, as can anyone else who has a real job outside of Wine.
Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list?
If you want support, head to wine-users or buy support for *Crossover Office* from Codeweavers.
This project needs a course in technical sales support. Good idea for the next WineConf!
What are we selling and who are we selling it to? I thought this was a FOSS project.
Remember you represent CodeWeavers, start acting like it.
First, he doesn't represent Codeweavers on the wine-devel mailing list. Second, there's nothing unprofessional about his actions.
On 9/25/06, jimtabor jimtabor@users.sourceforge.net wrote:
Every Wine developer needs to read this, http://www.codeweavers.com/services/ and http://www.codeweavers.com/services/wine .
What do these two pages have to do with Wine's Governance ?
It is your job to provide support for this product, I spend money and I need help, where do I go?
If you purchase CrossOver you will receive support, Wine is free software and support is provided through users helping other users, wine-users mailing list and #winehq on IRC
Are you going to piss me off by telling me to shut up and put up with the poor support from this mailing list?
Umm, NO! I'm going to tell you that you are a clueless troll who has no idea what so ever what your spouting off about!
This project needs a course in technical sales support. Good idea for the next WineConf!
Wine is free, so you get what you payed for. You are the one in need of some serious help! And don't bother to tell us how to run our conferences, we do a fine job on our own.
Tom
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 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 patch-daemon@winehq.org 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
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
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.
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).
-
James Hawkins -
Jeremy White -
jimtabor -
Mike McCormack -
Tom Wickline -
Troy Rollo