Sebastian Lackner sebastian@fds-team.de writes:
Based on a patch by Qian Hong.
I don't remember seeing any such patch. Qian is around, so I expect he should be able to submit his own work himself. Then you can submit your part as your own separate patch.
It's not a big deal for a small patch like this, but I don't want you to get into the habit of submitting patches containing bits and pieces of other people's work. I expect developers to stand behind their work, and take responsibility for getting their patches committed. Helping them is good, but taking over their work isn't.
On 10.06.2015 09:15, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
Based on a patch by Qian Hong.
I don't remember seeing any such patch. Qian is around, so I expect he should be able to submit his own work himself. Then you can submit your part as your own separate patch.
It's not a big deal for a small patch like this, but I don't want you to get into the habit of submitting patches containing bits and pieces of other people's work. I expect developers to stand behind their work, and take responsibility for getting their patches committed. Helping them is good, but taking over their work isn't.
Hello Alexandre,
I understand your concerns, but from my understanding you also don't want patches which for example temporarily introduce bugs, just to fix them shortly afterwards.
Qian Hongs original patch is available here: https://bugs.wine-staging.com/attachment.cgi?id=289&action=diff
The original version lacked proper parameter checking, and also didn't clear the full buffer. To be honest, there isn't really much left from the original version, but I still think its fair to give attribution to Qian. We were working together on fixing various msys2 bugs, and this was one of them.
Do you have a better suggestion how to deal with such situations in the future? In case of active contributors I can ask them to fix the most critical bugs of course, and afterwards put my patch on top of it. But what about inactive contributors? What about series of patches where the initial idea turned out to be wrong, and it was later fixed by a different contributor on top of the existing code?
I think it would be really nice to define a bit more exactly what is allowed/ preferred here and what not, especially when thinking about long standing problems like the inclusion of the Pulseaudio patchset.
Best regards, Sebastian
On 10.06.2015 11:00, Sebastian Lackner wrote:
I understand your concerns, but from my understanding you also don't want patches which for example temporarily introduce bugs, just to fix them shortly afterwards.
Qian Hongs original patch is available here: https://bugs.wine-staging.com/attachment.cgi?id=289&action=diff
The original version lacked proper parameter checking, and also didn't clear the full buffer. To be honest, there isn't really much left from the original version, but I still think its fair to give attribution to Qian. We were working together on fixing various msys2 bugs, and this was one of them.
See, but there's no way to know that when you submit a patch and not Qian.
Do you have a better suggestion how to deal with such situations in the future? In case of active contributors I can ask them to fix the most critical bugs of course, and afterwards put my patch on top of it. But what about inactive contributors? What about series of patches where the initial idea turned out to be wrong, and it was later fixed by a different contributor on top of the existing code?
I think the best way is to have original author submitting it in any case, after it's submitted you can help improving it right here on wine-devel, that everyone reads daily. Getting patch accepted is one goal, but not the only; educational value of getting a review is huge, what I believe we want (and author should too I think) is to make next patches from this author increasingly better, to the point when you don't have to improve anything.
I think it would be really nice to define a bit more exactly what is allowed/ preferred here and what not, especially when thinking about long standing problems like the inclusion of the Pulseaudio patchset.
That's different and should be separated in my opinion.
P.S. sorry if I disrupted this conversation.
Sebastian Lackner sebastian@fds-team.de writes:
I understand your concerns, but from my understanding you also don't want patches which for example temporarily introduce bugs, just to fix them shortly afterwards.
Qian Hongs original patch is available here: https://bugs.wine-staging.com/attachment.cgi?id=289&action=diff
The original version lacked proper parameter checking, and also didn't clear the full buffer. To be honest, there isn't really much left from the original version, but I still think its fair to give attribution to Qian. We were working together on fixing various msys2 bugs, and this was one of them.
Do you have a better suggestion how to deal with such situations in the future? In case of active contributors I can ask them to fix the most critical bugs of course, and afterwards put my patch on top of it. But what about inactive contributors? What about series of patches where the initial idea turned out to be wrong, and it was later fixed by a different contributor on top of the existing code?
What should happen is that Qian would submit a patch (to wine-patches, where everybody can see it) then if you see something wrong with it, instead of going ahead and making changes yourself, you tell Qian about it (and CC wine-devel so that we are all aware of what's going on), and let him address the issues and resubmit the patch. Repeat until the patch is good enough.
The process of having people fix their own patch is important. Not only it lets them learn from their mistakes, it also enables us to see where they are struggling, how they improve, how much they care, and builds the trust necessary to get patches approved. The process is at least as important as the final result.
That's my issue with wine-staging: it's trying to shortcut the process on the idea that if the final patch is OK, it doesn't matter how you got there. But to me, it does very much matter.
On 10.06.2015 10:38, Alexandre Julliard wrote:
What should happen is that Qian would submit a patch (to wine-patches, where everybody can see it) then if you see something wrong with it, instead of going ahead and making changes yourself, you tell Qian about it (and CC wine-devel so that we are all aware of what's going on), and let him address the issues and resubmit the patch. Repeat until the patch is good enough.
Hello Alexandre,
It is a bit unrealistic that from now on everyone is going to submit their raw draft patches to wine-patches, although they need additional work.
Moreover, as mentioned in the first mail, we were working together on fixing various msys2 bugs. If Qian would have preferred to tackle this problem himself, I would have given him some additional time of course, before I start with my own attempt. @Qian: Please correct me if I'm wrong, and you feel like I'm stealing your work.
The process of having people fix their own patch is important. Not only it lets them learn from their mistakes, it also enables us to see where they are struggling, how they improve, how much they care, and builds the trust necessary to get patches approved. The process is at least as important as the final result.
That's my issue with wine-staging: it's trying to shortcut the process on the idea that if the final patch is OK, it doesn't matter how you got there. But to me, it does very much matter.
I have to admit that the whole idea sounds nice, but based on my experience it doesn't really work very well. Such a method only works when every patch gets detailed and fair feedback, which is not the case at the moment. A lot of patches are not reviewed at all. I can perfectly understand that a lot of longtime wine developers don't want to mess around with patches of a very low quality, but what exactly should people learn from being ignored?
For others the feedback is sometimes a bit too strict if you ask me. Trying to submit an unfinished patch on the mailing list, will not result in an answer "let us work together to get this upstream", but often a kinda harsh and almost unfriendly answer, which leaves the impression that noone really cares about it. Also, in situations where it is not reasonable to ask for another iteration, or where the author has given up, it should be possible to integrate the last available version, to allow others to continue to work on it, which is also not the case right now.
Regarding the concern that Wine Staging makes it impossible to follow the process how the patches were created - do we know how many iterations developers do in their private repositories, before they finally submit it? Do we know how often people ask for feedback privately, before sending their patch? Obviously not. If there is a fear that upstream developers miss anything important, we should think about integrating Wine Staging a bit better into the upstream concept of submitting patches, instead of blaming it for everything. Wine Staging is not the problem, its an attempt to solve it, and only future will be able to tell if its the right approach.
Best regards, Sebastian
I didn't know it is not acceptable for Sebastian to take my simple hack and improve to an actual patch, instead I appreciate Sebastian's work. If Alexandre believe this is not acceptable, I suggest Sebastian to resend the same patch in his own name while replacing "Based on a patch by Qian Hong." to "Fix a bug spotted by Qian Hong."
I agree that the original work by myself is just a hack, which is just a proof of concept to show the bug, and the final version is already very different to the original one, I think Sebastian is serious to make sure credit my contribution, I appreciate that and I'm really fine if Sebastian resent in his name with the comment I suggested above.
We might be able to avoid similar cases in the future, but there seems no too many options this time since the patch is already there. Anyone against my suggestion?
Sebastian Lackner sebastian@fds-team.de writes:
On 10.06.2015 10:38, Alexandre Julliard wrote:
What should happen is that Qian would submit a patch (to wine-patches, where everybody can see it) then if you see something wrong with it, instead of going ahead and making changes yourself, you tell Qian about it (and CC wine-devel so that we are all aware of what's going on), and let him address the issues and resubmit the patch. Repeat until the patch is good enough.
Hello Alexandre,
It is a bit unrealistic that from now on everyone is going to submit their raw draft patches to wine-patches, although they need additional work.
Patches that are not meant to be committed can be sent to wine-devel for discussion, or attached to their corresponding bug.
I have to admit that the whole idea sounds nice, but based on my experience it doesn't really work very well. Such a method only works when every patch gets detailed and fair feedback, which is not the case at the moment. A lot of patches are not reviewed at all. I can perfectly understand that a lot of longtime wine developers don't want to mess around with patches of a very low quality, but what exactly should people learn from being ignored?
Sure, our community is not as nice as it could be, and a lot of us are burned out on trying to help newbies. But the community is the sum of its members, that's why we need people like you, with the skill and motivation to help people that others may not feel like helping.
So I think it's unfortunate that instead of joining us and help improve the behavior of the WineHQ community, you have chosen to fork your own separate community, and are actively encouraging people to give up on WineHQ and move over there.
Not only is it understandably perceived as a hostile move by a number of veteran devs, it also doesn't solve the issue, because as I explained, to get patches upstream people will be required to interact with the community here. So this is where the problems have to be addressed.
On 11.06.2015 07:27, Alexandre Julliard wrote:
Sure, our community is not as nice as it could be, and a lot of us are burned out on trying to help newbies. But the community is the sum of its members, that's why we need people like you, with the skill and motivation to help people that others may not feel like helping.
So I think it's unfortunate that instead of joining us and help improve the behavior of the WineHQ community, you have chosen to fork your own separate community, and are actively encouraging people to give up on WineHQ and move over there.
I never encouraged anyone to give up on WineHQ, and I also haven't given up WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I even advised them against doing this, when they contacted us about a year ago. In fact I would love to see a huge amount of our patches go upstream, and to work more directly together with upstream developers, with the common goal to make Wine better for the whole community.
But the problem is that noone of us has any influence to actually do the changes we would like to see in WineHQ directly - and you know how quickly discussions on the mailing lists usually disappear again, if they get an answer at all. There are a lot of things where WineHQ basically doesn't pay attention to the user or dev community at all. I am not going to list them all here again, but if there is actually interest to improve the situation, I will gladly talk to you or other people about these issues in detail.
Not only is it understandably perceived as a hostile move by a number of veteran devs, it also doesn't solve the issue, because as I explained, to get patches upstream people will be required to interact with the community here. So this is where the problems have to be addressed.
From my perspective there is nothing wrong with helping other people improving
their patches, working in a team together with other developers on fixing specific bugs, or picking up work by authors who gave up working on a specific area long time ago, this is basically what 99,99% of Wine Staging is about.
I hope you can understand, that we're not giving up this whole idea in a split second, even if there are people who don't like it. I am still convinced that this approach is better than just hoping for an upstream change. If / When there is actually a change (maybe this whole discussion helps a bit, to make people aware of the seriousness of all the problems), and it is no longer necessary to maintain a separate repository for it, that would also be fine for all of us.
Best regards, Sebastian
Sebastian Lackner sebastian@fds-team.de writes:
I never encouraged anyone to give up on WineHQ, and I also haven't given up WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I even advised them against doing this, when they contacted us about a year ago. In fact I would love to see a huge amount of our patches go upstream, and to work more directly together with upstream developers, with the common goal to make Wine better for the whole community.
I don't mean Fedora, though that's probably not a good thing either. My problem is the whole parallel process thing. In order for me and other devs to understand what's going on with your patches, we would now have to follow two bug trackers, two IRC channels, two mailing lists, github, etc. And of course it's even more confusing for users, who won't understand the distinction between the two.
Why not use the tools we already have (and improve them if they are insufficient)? If you truly want to work with upstream developers, why are you not discussing your patches on wine-devel or #winehackers?
Alexandre,
On 06/11/2015 10:14 AM, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
I never encouraged anyone to give up on WineHQ, and I also haven't given up WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I even advised them against doing this, when they contacted us about a year ago. In fact I would love to see a huge amount of our patches go upstream, and to work more directly together with upstream developers, with the common goal to make Wine better for the whole community.
I don't mean Fedora, though that's probably not a good thing either. My problem is the whole parallel process thing. In order for me and other devs to understand what's going on with your patches, we would now have to follow two bug trackers, two IRC channels, two mailing lists, github, etc. And of course it's even more confusing for users, who won't understand the distinction between the two.
Why not use the tools we already have (and improve them if they are insufficient)? If you truly want to work with upstream developers, why are you not discussing your patches on wine-devel or #winehackers?
That is partly history as Wine Staging started from the pipelight project. And partly because from the beginning Wine Staging was seen as an evil fork by some core Wine developers which has no place on the "true Wine" infrastructure and thus was met with active hostility.
But I agree, e.g. it is really stupid that Wine Staging has to spin up their own bugzilla. But what should they do else when the user bugs are closed on bugs.winehq.org with RESOLVED INVALID "evil 3rd party fork" even though the bug is in upstream Wine too. And that is not helped by you being "not convinced" and people having to prove them self before you giving out access on the official winehq infrastructure.
bye michael
On Thu, Jun 11, 2015 at 10:35:47AM +0200, Michael Stefaniuc wrote:
Alexandre,
On 06/11/2015 10:14 AM, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
I never encouraged anyone to give up on WineHQ, and I also haven't given up WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I even advised them against doing this, when they contacted us about a year ago. In fact I would love to see a huge amount of our patches go upstream, and to work more directly together with upstream developers, with the common goal to make Wine better for the whole community.
I don't mean Fedora, though that's probably not a good thing either. My problem is the whole parallel process thing. In order for me and other devs to understand what's going on with your patches, we would now have to follow two bug trackers, two IRC channels, two mailing lists, github, etc. And of course it's even more confusing for users, who won't understand the distinction between the two.
Why not use the tools we already have (and improve them if they are insufficient)? If you truly want to work with upstream developers, why are you not discussing your patches on wine-devel or #winehackers?
That is partly history as Wine Staging started from the pipelight project. And partly because from the beginning Wine Staging was seen as an evil fork by some core Wine developers which has no place on the "true Wine" infrastructure and thus was met with active hostility.
But I agree, e.g. it is really stupid that Wine Staging has to spin up their own bugzilla. But what should they do else when the user bugs are closed on bugs.winehq.org with RESOLVED INVALID "evil 3rd party fork" even though the bug is in upstream Wine too. And that is not helped by you being "not convinced" and people having to prove them self before you giving out access on the official winehq infrastructure.
I just looked at wine staging git.
It is basically a Wine fork already.
ls patches/|wc -l 228 ls patches/*/00*|wc -l 655
This includes some larger rewrites of subsystems, e.g. wininet-Cleanup
Some form of coordinated effort should probably be done to integrate things back to wine.
Also, I sent two more or less trivial fixes towards wine-patches, I would really encourage to send more obvious things directly to Wine itself.
Ciao, Marcus
On 06/11/2015 11:33 AM, Marcus Meissner wrote:
On Thu, Jun 11, 2015 at 10:35:47AM +0200, Michael Stefaniuc wrote:
Alexandre,
On 06/11/2015 10:14 AM, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
I never encouraged anyone to give up on WineHQ, and I also haven't given up WineHQ myself. If you mean the fact that Fedora switched to Wine Staging, I even advised them against doing this, when they contacted us about a year ago. In fact I would love to see a huge amount of our patches go upstream, and to work more directly together with upstream developers, with the common goal to make Wine better for the whole community.
I don't mean Fedora, though that's probably not a good thing either. My problem is the whole parallel process thing. In order for me and other devs to understand what's going on with your patches, we would now have to follow two bug trackers, two IRC channels, two mailing lists, github, etc. And of course it's even more confusing for users, who won't understand the distinction between the two.
Why not use the tools we already have (and improve them if they are insufficient)? If you truly want to work with upstream developers, why are you not discussing your patches on wine-devel or #winehackers?
That is partly history as Wine Staging started from the pipelight project. And partly because from the beginning Wine Staging was seen as an evil fork by some core Wine developers which has no place on the "true Wine" infrastructure and thus was met with active hostility.
But I agree, e.g. it is really stupid that Wine Staging has to spin up their own bugzilla. But what should they do else when the user bugs are closed on bugs.winehq.org with RESOLVED INVALID "evil 3rd party fork" even though the bug is in upstream Wine too. And that is not helped by you being "not convinced" and people having to prove them self before you giving out access on the official winehq infrastructure.
I just looked at wine staging git.
It is basically a Wine fork already.
ls patches/|wc -l 228 ls patches/*/00*|wc -l 655
This includes some larger rewrites of subsystems, e.g. wininet-Cleanup
Marcus, a lot of those patches were already in the Wine ballpark. The majority of those patches were picked up from wine-patches or from bugzilla.
Some form of coordinated effort should probably be done to integrate things back to wine.
Also, I sent two more or less trivial fixes towards wine-patches, I would really encourage to send more obvious things directly to Wine itself.
Correct. Somebody needs to just do it and see Wine Staging just as a patch summary like https://source.winehq.org/regressions is the regression summary. But instead of seeing it as an useful tool some core Wine developers prefer to look at it as an evil fork and actively fight it.
bye michael
Michael Stefaniuc mstefani@redhat.com writes:
But I agree, e.g. it is really stupid that Wine Staging has to spin up their own bugzilla. But what should they do else when the user bugs are closed on bugs.winehq.org with RESOLVED INVALID "evil 3rd party fork" even though the bug is in upstream Wine too. And that is not helped by you being "not convinced" and people having to prove them self before you giving out access on the official winehq infrastructure.
What infrastructure do you see that people should be given access to?
And yes, I agree that bugs are often being closed too easily, and that having a clearer policy there would be a good idea.
On Thu, 11 Jun 2015 21:45:29 +0900 Alexandre Julliard julliard@winehq.org wrote:
And yes, I agree that bugs are often being closed too easily, and that having a clearer policy there would be a good idea.
Yes, please. The response a user gets to a less-than-perfect bug report can vary wildly, based solely on the personality of the triager who happens to see the bug first, and this problem existed long before wine-staging came along.
Perhaps we could have a discussion of bug triage policies at WineConf, and draw up some guidelines for triagers?
On Thu, 11 Jun 2015 09:00:10 -0500 Rosanne DiMesio dimesio@earthlink.net wrote:
Perhaps we could have a discussion of bug triage policies at WineConf, and draw up some guidelines for triagers?
I phrased that badly. Just to be clear, what I mean is an open discussion, on the agenda.
I sure picked a crummy week to go on vacation - missed our best flame war in years! <grin>
But the problem is that noone of us has any influence to actually do the changes we would like to see in WineHQ directly - and you know how quickly discussions on the mailing lists usually disappear again, if they get an answer at all. There are a lot of things where WineHQ basically doesn't pay attention to the user or dev community at all. I am not going to list them all here again, but if there is actually interest to improve the situation, I will gladly talk to you or other people about these issues in detail.
I wanted to rename this thread, so no one missed the real subject of the discussion, and I wanted to respond to Sebastian's frustration.
In particular, I want to make it clear that if a discussion disappears, it's not because no one cares. I care deeply, and I know that Alexandre cares deeply. Michael cared deeply enough to hassle us into getting a Wineconf on the calendar (and he was right to suggest spring - it would be really nice to be discussing this in person).
The very last thing Wine needs is to lose any energy from any contributor. Further, I'm pretty sure I speak for everyone I know in the Wine community that we all want this to be fun, as much as possible, for everyone. [1]
With that said, I think this is a hard problem; I think it boils down to a request for Alexandre to be 'nicer', with varying shades of just what that means, and it's been discussed enough through the years that it's hard to discuss it constructively.
But if we've missed any 'easy' improvements; any concrete, actionable suggestions that have been overlooked or ignored, it might be helpful to post them here into this thread.
So far, the only one of those I read in this thread is to ask bugzilla workers to stop closing bugs that mention wine-staging with such rapid hostility, particularly if the bug is clearly a bug in mainline Wine. There seems to be consensus on that. Have we now done that? Is there any further action we need to take?
On to the harder problem ('be nice, Alexandre' <grin>), I don't think we tend to have good email archives of past discussions on this issue; I think we tend to have the most productive conversations in person at Wineconf. Our last major conversation, afair, was when Alexandre stunned us all by revealing the patches tracking page.
I'll try to respond to this email with my recollections, and my sense of the problem, and see if we can think of any constructive way to improve.
Cheers,
Jeremy
[1] Alexandre once famously compared Wine to a party (this was in the LGPL vs X11 license discussion, at Wineconf #1), in which he said the idea is that Wine is like a party amongst friends; some people bring beer, some people bring cups, some people bring tunes, and some people just come to dance. In his analogy, he went onto point out that a cover charge would spoil the fun, but I've always liked the idea of Wine as a party <grin>.
On 06/15/2015 06:31 PM, Jeremy White wrote:
<snip> With that said, I think this is a hard problem; I think it boils down to a request for Alexandre to be 'nicer', with varying shades of just what that means, and it's been discussed enough through the years that it's hard to discuss it constructively. <snip>
Everyone seems to forget that Alexandre is doing *a lot*. The simple patch queue management is not an easy task. I guess he classifies patches, reads them, looks at bugzilla entries, installs demo programs, tests patches, verifies them, discusses with other developpers, waits for author feedback... Understanding the *real* issue is also complex. He needs to know every windows component, how they are related..
People just want their patch committed because it-is-the-best-solution-ever but AJ has to keep the project moving the right way, avoiding regressions... Let's imagine you're at the other side with a continuous flow of patches...
Yes, he has to make choices (rejecting patches...) and sometimes, we don't get any input on what's wrong. But when he says 'doesn't compile here', it shows people don't even test their stuff. Clearly, Alexandre is doing a lot and .. for years so be nice with him ^^
What are the issues here ? It seems people want feedback. What's wrong with my patch ? Why is it pending ? Is my patch reviewed at all ? How to improve my patch, I'm a newbie...
And why ? I guess AJ does too many things, lacks time and manpower.
We can automate things: - compilation (done with testbot but not perfect yet) - formatting checks (spaces, if block on several lines or not...) - common issues (LPcrap...)
I don't know how statuses are managed but maybe a tool can be created or improved ? We can provide a mentor when a newbie posts a patch for the first time so that AJ can do other things in the meantime. (or delegate to wine-staging or a kind of sandbox but AJ doesn't like the idea) We could also use the 'sign-off' feature to delegate make a patch verified by a trusted dev (= having a list with domain <-> trusted dev). We can write standard commit rules and patch lifecycle rules so that everyone know where their patch is far from commit.
Any other thoughts ?
Am 15.06.2015 um 21:59 schrieb GOUJON Alexandre ale.goujon@gmail.com:
I don't know how statuses are managed but maybe a tool can be created or improved ? We can provide a mentor when a newbie posts a patch for the first time so that AJ can do other things in the meantime. (or delegate to wine-staging or a kind of sandbox but AJ doesn't like the idea) We could also use the 'sign-off' feature to delegate make a patch verified by a trusted dev (= having a list with domain <-> trusted dev). We can write standard commit rules and patch lifecycle rules so that everyone know where their patch is far from commit.
In theory we have all this, but it doesn't work as well as we want to. Henri checks d3d patches and Alexandre pretty much always commits the ones Henri acks (the only exception I've seen was when the test broke on AJ's machine but not mine or Henri's). Jacek and Piotr take care of mshtml & friends and msvc.
Problems arise in other areas. E.g. I've struggled to help people with patches for dplay and reg.exe. There are many parts of Wine that nobody feels really responsible for.
The other thing I am unhappy about is that sometimes all non-Alexandre people say "this is OK" but Alexandre still doesn't apply or provide feedback. Examples I can think of are my fix for bug 38394 (Alexandre told me once that he needs more time to check all possible side effects and that fixing the bug is probably more complicated) or Joachim Priesner's task dialog patches (https://www.winehq.org/pipermail/wine-patches/2015-February/137362.html is the latest version afaics)
Also I believe many people are afraid to say "this looks OK to me" because they think it might lower their Julliard Rank if the patch contains a stupid mistake. Reviewing is harder than writing patches.
Le lundi 15 juin 2015, 21:59:24 GOUJON Alexandre a écrit :
On 06/15/2015 06:31 PM, Jeremy White wrote:
And why ? I guess AJ does too many things, lacks time and manpower.
I agree, I think AJ and the core Wine developers are overloaded and maybe close to burn out. So they don't have the energy to build a welcoming developer community. As wineHQ is not a welcoming as it could be, the community does not grow, so they are not many new developers that can help the share the workload. So the core Wine developers are overloaded and we sadly close the circle :(
[..]
Any other thoughts ?
I have an idea to help AJ, but it might be a bit too "heretic":
-Give commit access to more people
For example I'd presume Henri and Stefan could be trusted with all the d3d stuff, and others with other parts.
So: - AJ would have more time for other important activities. - more people can give the final feedback if a patch is accepted or rejected
Cheers, Marc
PS: Just some facts about me. I'm not a wine developer(yet). I tried a bit earlier this year. My patches/messages didn't receive much feedback which I can understand giving the workload of the people here, so I kind of gave up.. But I would still like to hack on wine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-06-15 um 22:30 schrieb Marc Bessières:
For example I'd presume Henri and Stefan could be trusted with all the d3d stuff, and others with other parts.
We de facto have this setup already. Henri acks patches and Alexandre commits them. Maybe Alexandre spends 5 hours to read every patch Henri acks, but I don't think so.
One reason why Alexandre wants to be the only committer is tests. They may run successfully on my and Henri's machine but break on his. Then he has to run after whoever wrote the patch and whoever committed it to get the tests running again. Thus I suspect additional committers would increase Alexandre's workload rather than reduce it, especially in the highly platform dependent 3D area.
On 15 June 2015 at 21:59, GOUJON Alexandre ale.goujon@gmail.com wrote:
I don't know how statuses are managed but maybe a tool can be created or improved ? We can provide a mentor when a newbie posts a patch for the first time so that AJ can do other things in the meantime. (or delegate to wine-staging or a kind of sandbox but AJ doesn't like the idea) We could also use the 'sign-off' feature to delegate make a patch verified by a trusted dev (= having a list with domain <-> trusted dev). We can write standard commit rules and patch lifecycle rules so that everyone know where their patch is far from commit.
I've been watching the Wine project for years and a sign-off of sorts is something it really could use imho. There are several areas in Wine which Alexandre hasn't worked on at all and isn't the best person to judge a patch. I've used a "GTM" ("good to merge") system in both very large (wine-like) and very small codebases and projects. It's a type of implicit sign-off and a system that shines best on Github where commenting is cheap.
As a sidenote that's another issue I think: the only communication possible is through email. Email is formal. It's archived, it's spell-checked, it's proof-read and rewritten. So of course there's this huge investment to tell a contributor about something small and silly they're doing in a patch, which they might be completely oblivious to - no answer, frustration, duplication of efforts and sometimes patches are simply lost to that. In the large projects I've managed or been part of, line comments in patches are a huge deal. Being able to tell someone "you're doing something stupid here", rather than an implicit "proof read your patch because of its status in the queue", is a huge deal. Of course we can do that over email but not only do we need the right tools for it (to both do and keep track of), there is also the barrier of entry to email itself I was talking about. 2c
J. Leclanche
I'll try to respond to this email with my recollections, and my sense of the problem, and see if we can think of any constructive way to improve.
This is a long email; I'm trying to put down as much of the history as I recall, in an attempt to have it in written, archived format. I'm also trying to express my understanding of the current points of pain.
Disclaimer: these are my opinions, not those of Alexandre. I ascribe motivations to him that I think are essentially correct, but I rely on him to correct me where I've got it wrong.
First, we always seem to agree that Alexandre is fscking smart; that he is better qualified than anyone we know to judge what comprises good code, and what will work well with Wine.
Further, we generally settle in to accepting the 'benevolent dictatorship'; that it is efficient to have him as the sole maintainer, and that he is sufficiently smart, and his (!Julliard)Rank is sufficiently high that we trust him to do it well.
Second, we often explore whether or not Alexandre has a bandwidth problem; that is, if he just had more free time, could he respond more ably. (The "he's not an asshole, he's just swamped" theory <grin>). He assures us time and time again that is not the case - that he handles the work load okay, and he is just an asshole <truly evil grin> [1].
As a subset, we often talk about whether or not there are tools that would better help him; the current patch page is, as far as we know, sufficient for him, although he could really use a stronger WineTestBot.
Then, in addition to that, Alexandre was burned badly in the early days of Wine by taking in patches that were useful to a user, but were poorly formed. Those patches often went on to cause later problems in Wine, and promises that "I'll fix it later" often didn't materialize. By contrast, having the nagging state of: "This is ridiculous! There is a patch *here* that fixes *obviously important problem* there, why the hell isn't it in Wine" has, through the years, served to eventually get the right patches into Wine. (One famous example was the xinput2 patch set, and the current pulse and command stream patches are also clear cases of this phenomenon).
Further, it is getting increasingly rare that a valuable patch is isolated. He has much more relaxed standards for accepting code into obscure_and_completely_unimplemented.dll than for accepting wine server or ntdll changes. And changes to key areas have a nasty habit of causing subtle problems elsewhere, or in the future.
Thus, he has a fairly strong incentive to hold out for the very best code he can get, and history has proven that if he holds out for higher quality code, he can eventually get it into Wine.
Next, as Alexandre has recently articulated in this thread, he has a process he likes Wine contributors to follow to establish trust with him, and a persons trust (humorously known as JulliardRank) is absolutely critical to his acceptance of his patch.
He has some personality quirks; he is clearly striving to hold the world record in information density; trying to use the fewest words possible (where as I strive for the opposite <grin>). That sometimes comes across as rude or abrupt, and is (usually) not intended as such. He's also generally content with the 'bug-me-if-I-dropped-your-patch' method, which often surprises people.
I think Alexandre also has a hard time understanding some people's mental gaps; what is obvious to him, or something he thinks should be obvious to you, will not become obvious to you, no matter how long you stare at his words (or lack of words :-/).
And then, rightly or wrongly, the amount of energy Alexandre is willing to spend on someones patch is inversely proportional to their trust rank. Gradually, over time, if you cannot improve that rank, he is willing to to invest less and less in helping you get that patch in.
That's frustrating, because he is often the only real gatekeeper. There is no appeals process, and often no other developer has constructive advice to offer.
I think Michael touched on the most frustrating possible outcome: to be a developer, with evidence that you're smart and capable in your own right, with a patch that you worked day and night on *that solves a real problem*. Now this patch looks right to you, even after hours of study, and it clearly solves a user problem, and it passes the regression tests. Then you send it in...and it's ignored, or it is rejected because Alexandre 'is not convinced'.
It hurts; it pisses you off; you feel trapped with no way forward. That sucks.
Of course, there are two divergent narratives: one is that of a good, valuable developer, being wrongly discouraged. The second is a developer trying to help, but not really able or willing to spend the time to create quality code. We want to invest time in the first developer, but not necessarily the second, and it's very difficult to distinguish between the two. (And there are sub cases; a one shot developer who finds + fixes a bug, throws us her patch, but then doesn't want to bother hanging around to see the patch through. It's probably useful to capture the knowledge in that patch, and maybe even have a different developer respin it and get it in, much as Alexandre is resistant to that).
We have, several times in the past, resolved to try to have ambassadors to help newbies. People to try to help new contributors navigate this process, and to feel encouraged to have the patience and gumption to see their patch through. I think there is value in that effort, but it clearly has not been enough, given the current frustration levels.
The only other thing on this topic that I can recall is that there are parts of the process that were obvious to Alexandre, and not always to others. The concept of JulliardRank; the concept that bugging him about patches is perfectly fine. But I believe that all of that was 'fixed' by amending the Wiki. It may be that it's not as 'fixed' as we'd like :-/.
At any rate, sorry for the long email; just trying to be complete.
If I've misunderstood frustrations or points of pain, or if there are ideas for changes, please chime in.
Cheers,
Jeremy
[1] The dirty secret, as much as he will insist otherwise, is that he's actually a pretty nice guy. The level of vitriol on the Wine mailing list is a fraction of that produced on many other projects, and I think Alexandre really does not like hurting peoples feelings. But the point is that he's willing to be the asshole if that's what it takes to ensure the best result for Wine. If you think about it, that's a pretty gracious gift.
Wow a nice little flame war and everyone is trying their best to be nice. That takes the fun out of a flame war people!
Disclaimer, all opinions are mine and in NO way shape or form the opinion of WineHQ. I encourage anyone here to swiftly correct any mistake that I might make, my opinion isn't a mistake BTW.
Disclaimer #2 if the work FUCK offends you then stop reading here.
Is Alexandre an ASSHOLE?
Absolutely not, if anyone would think this then they have never met the man in person! He is actually one of the nicest people that I've ever met.
Is their really a AJ rank?
Yes, and I have the highest all-time score, and this is the secret and It's simple. You write a patch it gets rejected, you tweak the patch same treatment. What the fuck?? Is what your saying, if not screaming! The secret is to pester the shit out of him, asking questions and keep submitting alterations. You will get it right or he will fix your fuck ups in the hopes that you will leave him the hell alone.
This shows determination, persistence, a willingness to make a thousand fuck ups in the hopes you will one day figure out what your doing and get it right once.
Why am I the highest scorer? Everything I submitted got accepted after I drove him to madness. :)
My point is, "I" believe persistence and a willingness to stick the process out goes a very long way on the AJ rank.
Should their be multiple people with commit rights?
I think NO, It's just a entrance to a rabbit hole.
Will patches get overlooked?
Yes, It's just that simple...
Now to what this thread, overly nice flame war is about...
Should winehq acknowledge and to a degree work with wine-staging ???
That's really what ALL of this is about isn't it?
I personally like the idea of wine-staging as a holding que for the best of the passed over patches. Not to mention the project is becoming popular and has a growing user base.
I believe the project should be seen as a asset to winehq
The problem is you can't scrape winehq patches rebrand them and then submit them thinking they will be accepted a second time around. It's just not that simple...
"I" believe the patches need to be reviewed, cut into small chunks, and the submitter knowing your going to need persistence and the attitude of FUCK YOU... I'm not going anywhere until this shit is fixed and accepted.
So the question is still open, is wine-staging seen as a asset or a thorn? Can everyone play nice together at this party?
I believe so, It's just a matter of getting everything out in the open, everyone cursing allot, finding solutions, then kiss and make up..
Can someone pass the chips please
Tom On Jun 16, 2015 4:29 AM, "Jeremy White" jwhite@codeweavers.com wrote:
I'll try to respond to this email with my recollections, and my sense of the problem, and see if we can think of any constructive way to improve.
This is a long email; I'm trying to put down as much of the history as I recall, in an attempt to have it in written, archived format. I'm also trying to express my understanding of the current points of pain.
Disclaimer: these are my opinions, not those of Alexandre. I ascribe motivations to him that I think are essentially correct, but I rely on him to correct me where I've got it wrong.
First, we always seem to agree that Alexandre is fscking smart; that he is better qualified than anyone we know to judge what comprises good code, and what will work well with Wine.
Further, we generally settle in to accepting the 'benevolent dictatorship'; that it is efficient to have him as the sole maintainer, and that he is sufficiently smart, and his (!Julliard)Rank is sufficiently high that we trust him to do it well.
Second, we often explore whether or not Alexandre has a bandwidth problem; that is, if he just had more free time, could he respond more ably. (The "he's not an asshole, he's just swamped" theory <grin>). He assures us time and time again that is not the case - that he handles the work load okay, and he is just an asshole <truly evil grin> [1].
As a subset, we often talk about whether or not there are tools that would better help him; the current patch page is, as far as we know, sufficient for him, although he could really use a stronger WineTestBot.
Then, in addition to that, Alexandre was burned badly in the early days of Wine by taking in patches that were useful to a user, but were poorly formed. Those patches often went on to cause later problems in Wine, and promises that "I'll fix it later" often didn't materialize. By contrast, having the nagging state of: "This is ridiculous! There is a patch *here* that fixes *obviously important problem* there, why the hell isn't it in Wine" has, through the years, served to eventually get the right patches into Wine. (One famous example was the xinput2 patch set, and the current pulse and command stream patches are also clear cases of this phenomenon).
Further, it is getting increasingly rare that a valuable patch is isolated. He has much more relaxed standards for accepting code into obscure_and_completely_unimplemented.dll than for accepting wine server or ntdll changes. And changes to key areas have a nasty habit of causing subtle problems elsewhere, or in the future.
Thus, he has a fairly strong incentive to hold out for the very best code he can get, and history has proven that if he holds out for higher quality code, he can eventually get it into Wine.
Next, as Alexandre has recently articulated in this thread, he has a process he likes Wine contributors to follow to establish trust with him, and a persons trust (humorously known as JulliardRank) is absolutely critical to his acceptance of his patch.
He has some personality quirks; he is clearly striving to hold the world record in information density; trying to use the fewest words possible (where as I strive for the opposite <grin>). That sometimes comes across as rude or abrupt, and is (usually) not intended as such. He's also generally content with the 'bug-me-if-I-dropped-your-patch' method, which often surprises people.
I think Alexandre also has a hard time understanding some people's mental gaps; what is obvious to him, or something he thinks should be obvious to you, will not become obvious to you, no matter how long you stare at his words (or lack of words :-/).
And then, rightly or wrongly, the amount of energy Alexandre is willing to spend on someones patch is inversely proportional to their trust rank. Gradually, over time, if you cannot improve that rank, he is willing to to invest less and less in helping you get that patch in.
That's frustrating, because he is often the only real gatekeeper. There is no appeals process, and often no other developer has constructive advice to offer.
I think Michael touched on the most frustrating possible outcome: to be a developer, with evidence that you're smart and capable in your own right, with a patch that you worked day and night on *that solves a real problem*. Now this patch looks right to you, even after hours of study, and it clearly solves a user problem, and it passes the regression tests. Then you send it in...and it's ignored, or it is rejected because Alexandre 'is not convinced'.
It hurts; it pisses you off; you feel trapped with no way forward. That sucks.
Of course, there are two divergent narratives: one is that of a good, valuable developer, being wrongly discouraged. The second is a developer trying to help, but not really able or willing to spend the time to create quality code. We want to invest time in the first developer, but not necessarily the second, and it's very difficult to distinguish between the two. (And there are sub cases; a one shot developer who finds + fixes a bug, throws us her patch, but then doesn't want to bother hanging around to see the patch through. It's probably useful to capture the knowledge in that patch, and maybe even have a different developer respin it and get it in, much as Alexandre is resistant to that).
We have, several times in the past, resolved to try to have ambassadors to help newbies. People to try to help new contributors navigate this process, and to feel encouraged to have the patience and gumption to see their patch through. I think there is value in that effort, but it clearly has not been enough, given the current frustration levels.
The only other thing on this topic that I can recall is that there are parts of the process that were obvious to Alexandre, and not always to others. The concept of JulliardRank; the concept that bugging him about patches is perfectly fine. But I believe that all of that was 'fixed' by amending the Wiki. It may be that it's not as 'fixed' as we'd like :-/.
At any rate, sorry for the long email; just trying to be complete.
If I've misunderstood frustrations or points of pain, or if there are ideas for changes, please chime in.
Cheers,
Jeremy
[1] The dirty secret, as much as he will insist otherwise, is that he's actually a pretty nice guy. The level of vitriol on the Wine mailing list is a fraction of that produced on many other projects, and I think Alexandre really does not like hurting peoples feelings. But the point is that he's willing to be the asshole if that's what it takes to ensure the best result for Wine. If you think about it, that's a pretty gracious gift.
On Tue, 16 Jun 2015 12:50:02 +0800 Tom Wickline twickline@gmail.com wrote:
I personally like the idea of wine-staging as a holding que for the best of the passed over patches. Not to mention the project is becoming popular and has a growing user base.
That growing user base is thoroughly confused about the relationship between the two projects. I've been asked on the forum "isn't wine-staging just wine development?" Wine-staging users are reporting bugs fixed here when they haven't been, and it's not only inexperienced users. I've seen AppDB maintainers post info implying that patches in wine-staging will inevitably be included in Wine. That confusion is not the users' fault: they are routinely being referred to wine-staging by triagers and developers in our bugzilla. It's hardly surprising that they would think wine-staging is now the development branch.
On Mon, Jun 15, 2015 at 03:29:10PM -0500, Jeremy White wrote:
I'll try to respond to this email with my recollections, and my sense of the problem, and see if we can think of any constructive way to improve.
This is a long email; I'm trying to put down as much of the history as I recall, in an attempt to have it in written, archived format. I'm also trying to express my understanding of the current points of pain.
One observation is that Sebastian and Michael from wine-staging can currently generate way more input of good patches (even if not Alexandre style perfect) than Alexandre can currently take on.
They are also good in picking up lots of small patches that are otherwise left.
So wine-staging can currently take more input that regular Wine and so can progress faster.
So part of the problem is a input-bandwith problem I think.
(One part)
Ciao, Marcus
On 15 June 2015 at 18:31, Jeremy White jwhite@codeweavers.com wrote:
With that said, I think this is a hard problem; I think it boils down to a request for Alexandre to be 'nicer', with varying shades of just what that means, and it's been discussed enough through the years that it's hard to discuss it constructively.
For what it's worth, most requests seem to be either about lowering the acceptance threshold in some way (e.g. wrt. authorship, code quality, amount of tests, etc.) or providing more hand-holding. I think the majority of the request in the first category are just bad ideas. The second category are usually things that would be nice in theory, but for which people seriously underestimate the amount of work that would be involved. For things in the second category in particular it becomes an issue of weighing "How much useful work can I do in the time it's going to take me to help this person." vs. "How much useful work is this person likely to produce after I've helped him/her." Some people just need a little help to get used to the process. Some people might become competent developers once they e.g. have another 5 years of experience. Some people simply never will.
Perhaps another interesting thing to note is that the people that tend to become most frustrated are the ones that come to the project with the approach of "I need to fix this one specific application/bug right now". They tend to run into all the hard DIB-engine-level bugs, and since they need to fix it right now building up some experience and trust isn't an option, and they pretty much get stuck in that position. Arguably that doesn't have so much to do with the development model as it does with available developer capacity to fix incoming bugs.
So far, the only one of those I read in this thread is to ask bugzilla workers to stop closing bugs that mention wine-staging with such rapid hostility, particularly if the bug is clearly a bug in mainline Wine. There seems to be consensus on that. Have we now done that? Is there any further action we need to take?
I think it was more general than that, about discussing bugzilla policy in general. The plan seems to be to do that at WineConf, although personally I think it's one of those things that can happen just as well on the mailing list.
On 15 June 2015 at 22:14, Stefan Dösinger stefandoesinger@gmail.com wrote:
Also I believe many people are afraid to say "this looks OK to me" because they think it might lower their Julliard Rank if the patch contains a stupid mistake. Reviewing is harder than writing patches.
For me personally, it's more that there are various levels of review you can do. If I explicitly ack a patch to Alexandre, unless stated otherwise, that means it's something I'd personally commit. Aside from just reading/checking the patch, that implies that I've applied it, ran the tests on it, ran the tests on Windows if it touches the tests (because, the testbot and D3D), and so on. For D3D, I care enough to do that, but for most other areas I don't, and I might just point out issues if they happen to catch my eye. These days, I have enough to do that I don't even read a lot of patches though. (On that subject, if you want people to actually read and reply to your patches, try using git send-email, or at least sending them inline.)
On 15 June 2015 at 22:30, Marc Bessières marc.bessieres@mykolab.com wrote:
I agree, I think AJ and the core Wine developers are overloaded and maybe close to burn out. So they don't have the energy to build a welcoming developer community. As wineHQ is not a welcoming as it could be, the community does not grow, so they are not many new developers that can help the share the workload. So the core Wine developers are overloaded and we sadly close the circle :(
I suppose so, on some level anyway. At the same time, while I may personally feel a bit thin-spread at the moment, I'm pretty sure Alexandre is currently giving people more feedback than he ever has before. So I'm not so sure I necessarily see that correlation. I also have the impression that compared to e.g. 5-10 years ago the average skill level of potential new contributors has dropped a bit, and perhaps that generally speaking simply fewer people are interested in "proper" (i.e., not involving browsers, phones or tablets) software development.
Alexandre Julliard julliard@winehq.org wrote:
I have to admit that the whole idea sounds nice, but based on my experience it doesn't really work very well. Such a method only works when every patch gets detailed and fair feedback, which is not the case at the moment. A lot of patches are not reviewed at all. I can perfectly understand that a lot of longtime wine developers don't want to mess around with patches of a very low quality, but what exactly should people learn from being ignored?
Sure, our community is not as nice as it could be, and a lot of us are burned out on trying to help newbies. But the community is the sum of its members, that's why we need people like you, with the skill and motivation to help people that others may not feel like helping.
So I think it's unfortunate that instead of joining us and help improve the behavior of the WineHQ community, you have chosen to fork your own separate community, and are actively encouraging people to give up on WineHQ and move over there.
Alexandre, for some reason you are intentionally ignoring the fact that creation of wine-staging is the *result* of winehq behaviour, not something that has appeared out of the air. I'm not going to repeat again and again about ignored patches (silently rejected or marked as 'pending'), absence of constructive and technical comments, etc. etc. Obviously wine-staging maintainers started to work with winehq using available tools like wine-patches, wine-devel, wine-bugzilla, patch tracker, but once they stumbled upon some hard to overcome things they have no control over, and after many attempts to discuss and even persuade to change something on winehq side they decided to create wine-staging.
Not only is it understandably perceived as a hostile move by a number of veteran devs, it also doesn't solve the issue, because as I explained, to get patches upstream people will be required to interact with the community here. So this is where the problems have to be addressed.
The source of the problem is on winehq side, ignring this fact won't change anything. And what is the reason of hostality of that "veteran devs"? That somebody spends their free spare time taking the patches from wine-patches and wine-bugzilla, maintains and improves them, and helps other developers with improving their work by openly suggesting the changes and providing honest and high quality help without being paid any cent?
-
Alexandre Julliard -
Dmitry Timoshkov -
GOUJON Alexandre -
Henri Verbeet -
Jeremy White -
Jerome Leclanche -
Marc Bessières -
Marcus Meissner -
Michael Stefaniuc -
Nikolay Sivov -
Qian Hong -
Rosanne DiMesio -
Sebastian Lackner -
Stefan Dösinger -
Tom Wickline