2015-06-18 2:08 GMT-06:00 Alexandre Julliard julliard@winehq.org:
So now I want to take a step back, and take the time to look at what we are doing wrong, and listen to new ideas. I'd like to encourage everyone, but especially people who are disgruntled or have given up hope that we'd ever change, to send (either in this thread or by private mail) their suggestions for what we should be doing differently, and how.
As a relatively new Wine developer, I submitted a UTF-7 implementation copied from ReactOS, but it was rejected without explanation. After some prodding, I was told that I needed to rewrite the code from scratch.[2] Then, after I rewrote the patches, I was told to put the implementation in kernel32 instead of libwine.[3] The next patchset was ignored, but I finally got a couple of cryptic messages about a buffer overflow and table-based tests.[4][5] Later I got more cryptic messages about needing more tests, but again I was not told what needed to be tested, just "think about it".[6][7] Finally I was told "this isn't going anywhere",[9] "you have nowhere near enough tests"[10] and "if you're too stupid to know what you're doing wrong then you shouldn't contribute".[11]
The above process literally lasted from January to December 2012. After that, I was so upset with the Wine project and AJ in particular that I did not submit a single patch to Wine for more than a year.[12] When I finally decided to try submitting the UTF-7 patches again in October 2014, I begged AJ for feedback and once again got nothing specific.[13] In desperation, I turned to IRC and was invited to participate in Wine Staging. They patiently provided specific, line-by-line feedback and even helped rewrite the code in a couple of places. They also accepted the code into their fork to get some real-world testing.[14] By the end of November 2014 (less than two months later!) the patchset was accepted into mainline Wine.[12]
Wine has been one of the worst, if not the worst, open source project I have ever worked with. (I think it's a tie between Wine and Qt's QSerialPort module, but that's another story.) My UTF-7 experience illustrates exactly why we need Wine Staging or something like it: Without the detailed feedback that the Wine Staging developers provided, this feature would have never been accepted. Furthermore, I would not have learned the tips and tricks that I needed to know to write acceptable patches in the future.
The idea that all discussion and development needs to happen on wine-devel and wine-patches in order to gain trust is BS. AJ was unwilling to take more than a glance at the UTF-7 patches until they had gone through probably a hundred iterations on GitHub and the wine-staging IRC channel. In my experience, AJ is far more likely to accept a patch done right the first time than a patch submitted 12 times because the submitter keeps finding problems with it.
Alexandre, the best thing you could do differently is to provide verbose feedback on every patch. You have been working on Wine for a very long time and what is obvious to you is not obvious to everyone else. If you don't have time to write feedback yourself, ask another Wine developer to do it. Ideally we would have a list of trusted advisors for each program and DLL, people who are available to answer questions in their areas of expertise. It would also be a good idea to notice new developers, assign tutors to them, and have the tutors welcome the new developers and offer to answer questions.
Please understand that I like Wine, I want to attract new Wine developers, and I want to see it become the most popular Windows API implementation. I hope you can take this email as constructive criticism without it negatively affecting my Julliard Rank™ ;-)
-Alex
[1] https://www.winehq.org/pipermail/wine-devel/2012-January/093705.html [2] https://www.winehq.org/pipermail/wine-devel/2012-May/095451.html [3] https://www.winehq.org/pipermail/wine-devel/2012-July/096531.html [4] https://www.winehq.org/pipermail/wine-devel/2012-August/096867.html [5] https://www.winehq.org/pipermail/wine-devel/2012-August/096872.html [6] https://www.winehq.org/pipermail/wine-devel/2012-September/096901.html [7] https://www.winehq.org/pipermail/wine-devel/2012-September/096910.html [8] https://www.winehq.org/pipermail/wine-devel/2012-December/097994.html [9] https://www.winehq.org/pipermail/wine-devel/2012-December/098015.html [10] https://www.winehq.org/pipermail/wine-devel/2012-December/098036.html [11] https://www.winehq.org/pipermail/wine-devel/2012-December/098051.html [12] https://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&am... [13] https://www.winehq.org/pipermail/wine-devel/2014-October/105402.html [14] https://github.com/wine-compholio/wine-staging/commit/04467e7e68b12850349fbe...
On Sat, Jun 20, 2015 at 1:34 AM, Alex Henrie alexhenrie24@gmail.com wrote:
2015-06-18 2:08 GMT-06:00 Alexandre Julliard julliard@winehq.org: As a relatively new Wine developer, I submitted a UTF-7 implementation ... [6][7] Finally I was told "this isn't going anywhere",[9] "you have nowhere near enough tests"[10] and "if you're too stupid to know what you're doing wrong then you shouldn't contribute".[11]
-Alex
You make it sound like Alexandre said you were an idiot in [11], by using a supposed quote from him.
He said "If you can't think of anything to test beyond the handful of cases you already have, then you shouldn't be implementing that function.".
Regardless of any criticism you might have on AJ's behaviour/communication skills, don't misquote him. That's dishonnest.
Frédéric
Regardless of any criticism you might have on AJ's behaviour/communication skills, don't misquote him. That's dishonnest.
Actually, I think this quote pair is a very useful example.
Alex may not have quoted exactly what Alexandre said, but he did express *how it felt to him*. It doesn't making anyone wrong or right, but it can explain how two well intentioned people can perceive events very differently.
I want to highlight a few other portions of what Alex said:
In desperation, I turned to IRC and was invited to participate in Wine Staging. They patiently provided specific, line-by-line feedback and even helped rewrite the code in a couple of places. They also accepted the code into their fork to get some real-world testing.[14] By the end of November 2014 (less than two months later!) the patchset was accepted into mainline Wine.[12]
I just want to observe how absolutely fantastic that is. I don't know why our best efforts to engender that sort of thing through the years have never worked well, but if there is one quality of wine-staging we need to fiercely protect and support, it is that encouragement and positive engagement.
The idea that all discussion and development needs to happen on wine-devel and wine-patches in order to gain trust is BS. AJ was unwilling to take more than a glance at the UTF-7 patches until they had gone through probably a hundred iterations on GitHub and the wine-staging IRC channel. In my experience, AJ is far more likely to accept a patch done right the first time than a patch submitted 12 times because the submitter keeps finding problems with it.
I did want to take a second to parse out one implication from what you've said. The code, as you were able to initially form it, was a hundred revisions away from being ready for acceptance into Wine.
That suggests that Alexandre's response to your initial patch series was, essentially, correct.
The tragedy, I think, is that you were left feeling rejected, hopeless, and desperate. That you did not feel like you had a path forward.
I appreciate that you would have liked Alexandre to provide the guidance that the wine-staging folks eventually did provide; that seems like an awful lot to demand of him.
I guess our challenge is to find a way to make the connection to the positive engagement you did eventually receive.
It would be nice if that encouragement could be happening 'here' instead of 'over there', but if the isolation is part of what makes it work, maybe that's something we should consider.
Cheers,
Jeremy
On 6/20/15 11:41 AM, Jeremy White wrote:
I guess our challenge is to find a way to make the connection to the positive engagement you did eventually receive.
It would be nice if that encouragement could be happening 'here' instead of 'over there', but if the isolation is part of what makes it work, maybe that's something we should consider.
It seems to me that people with differences benefit from having a some space between them, but that doesn't mean they have to have entirely separate communities. Families who don't all like the same kind of television can buy two TVs and watch their own shows, but continuing to share the rest of the house.
I think there could be a branch in winehq git called 'staging,' with someone other than Alexandre having commit access, and bugs in the 'staging' branch could be considered legitimate in the winehq bug tracker. There would need to be new norms for patch submission. There would need to be a good maintainer for the second branch. Michael said near the start of the thread that "access on the official winehq infrastructure" was a problem for some people. Maybe commit access to a second git branch would be a start.
One could hope that a second branch would give both "sides" enough room to be happy and productive, but stay together in the same community. Problems seem to center around tolerance of different goals, approaches, and skill levels. Disagreements often happen at the point when patches are rejected. With a second branch, more patches could be accepted, but committed *in the branch where they fit best*, and maybe there would be less contention. Ideally there would be shared goals both to allow some experimentation in the 'staging' branch and eventually to get all features in a 'polished' state and into 'master.'
Keeping the diversity of goals, approaches, and even skill levels all in the same community seems worthwhile to me if it is possible. Making productive use of a second branch over the long term is not a trivial change. It just seems like having people with differences stay close enough together to continue influencing each other is a good thing.
On Sat, Jun 20, 2015 at 12:33 PM, Josh Dubois wrote:
Michael said near the start of the thread that "access on the official winehq infrastructure" was a problem for some people. Maybe commit access to a second git branch would be a start.
From personal experience, I don't think it's just the git repo. One time, when I didn't feel up to working on Wine code but still wanted to help some in my free time, I started looking into bug triage. I had Bugzilla and AppDB accounts, a subscription to the bugs maillist, had already practiced testing on developmental build of Wine, and read what instructions I could find on the wiki and Dan Kegel's page.
In the end though, beyond just adding more comments to the bottom of the page, I couldn't figure out how anyone earns the rights necessary to fix tags or recategorize bugs. I even tried emailing the Bugzilla admin to ask but never heard back. Honestly, beyond some of the developers and site admins, whom I assume have elevated rights across WineHQ, I still don't know who processes the bug reports.
With a second branch, more patches could be accepted, but committed *in the branch where they fit best*, and maybe there would be less contention. Ideally there would be shared goals both to allow some experimentation in the 'staging' branch and eventually to get all features in a 'polished' state and into 'master.'
Isn't the whole issue with wine-staging patches that they're more ad-hoc/hackish then we want for Wine proper? Correct me if I'm wrong, but if you take an ad-hoc fix that suddenly makes something work, then replace the programmatic output with debug info, don't you have a test case? I'm just wondering if maybe our thinking about wine & wine-staging is (to quote The Dude) too uptight. Perhaps instead of seeing it as:
Diablo fan makes one-off fix -> Pessimists shake heads & optimists start pushing that rock uphill -> Maybe once in a while, it becomes part of the Wine *program*
... we should see it as more ...
Diablo fan makes one-off fix -> Someone distills the effective knowledge into a test -> It moves into the Wine *test-suite* <- Wine-staging or AppDB points out the original patch as a stop-gap.
On Sat, Jun 20, 2015 at 10:41 AM, Jeremy White wrote:
I guess our challenge is to find a way to make the connection to the positive engagement you did eventually receive.
Since I've worked on other parts of WineHQ, not Wine itself, my experience might be different, but I've never really had problems with negative engagement so much as no engagement at all. That's not universally true: you were very helpful when I was starting to work on the website some, Jeremy. Plus Andre H and Dimi P were really good about keeping in touch with thoughts while I redid the wiki.
Otherwise though, it seems sometimes like almost everything that isn't a direct comment on a patch just falls through the cracks on the mail-list. I get the impression IRC might be a little better in that regard, but sometimes it's not easy to stay on IRC. When I was working on the wiki, I actually didn't even have internet access at my flat. Even then, it might be misleading to view it as primarily a communication issue. I think it's more a symptom of the coordination problems I mentioned in my first email.
- Kyle
On Jun 21, 2015 2:58 AM, "Kyle Auble" kyle.auble@zoho.com wrote:
In the end though, beyond just adding more comments to the bottom of the page, I couldn't figure out how anyone earns the rights necessary to fix tags or recategorize bugs. I even tried emailing the Bugzilla admin to ask but never heard back. Honestly, beyond some of the developers and site admins, whom I assume have elevated rights across WineHQ, I still don't know who processes the bug reports.
There are several people (myself, Focht, Bruno, Bela, Nikolay, etc.).
I didn't realize there was a Bugzilla admin email alias, I've asked Jeremy Newman to add me, so now someone active is watching it :). For future reference though, if in doubt, email wine-devel or ask on #winehackers.
(If you still need permission to triage, send me an email, though I won't have a chance to do so for a few days, currently traveling.)
-Austin
On 06/24/2015 08:18 AM, Austin English wrote:
On Jun 21, 2015 2:58 AM, "Kyle Auble" <kyle.auble@zoho.com mailto:kyle.auble@zoho.com> wrote:
In the end though, beyond just adding more comments to the bottom of the page, I couldn't figure out how anyone earns the rights necessary to fix tags or recategorize bugs. I even tried emailing the Bugzilla admin to ask but never heard back. Honestly, beyond some of the developers and site admins, whom I assume have elevated rights across WineHQ, I still don't know who processes the bug reports.
I didn't realize there was a Bugzilla admin email alias, I've asked Jeremy Newman to add me, so now someone active is watching it :)
Cool, and I just realized that it was Jeremy Newman I had been talking to when I was working on the webpage (it's been a while). Either way, to both Jeremy-s and everyone else, keep up the good work.
For future reference though, if in doubt, email wine-devel or ask on #winehackers.
Will do, and to be fair, unless it's a critical life goal, I'm not the most persistent person so I probably should have asked around more. Quick question about #winehackers etiquette: if I can't be on all the time and want to use an IRC bouncer, is it ok to spread out conversations over time? Or is that seen as rude; should I only keep conversations going so long as they're relatively active?
(If you still need permission to triage, send me an email, though I won't have a chance to do so for a few days, currently traveling.)
I'm going through a move right now, but when things are more stable, I might email you then. I also just realized that even without triage permissions, maybe I could have still emailed to check in with reporters about abandoned bugs (I don't remember if standard rights let you email other users). First though, I might try to get a good grip on building and linking multiarch wine, then see if I can streamline it at all (I know I complained about that in particular, but I can get things done if I focus so I should code, not kvetch).
- Kyle
-
Alex Henrie -
Austin English -
Frédéric Delanoy -
Jeremy White -
Josh DuBois -
Kyle Auble