Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1].
May I suggest you eliminate those hacks by merging them into the Wine codebase? Right now I have a feeling that Wine is wonderful, but Codeweavers is evil. It seems that this feeling is shared by many non-Codeweavers Wine developers. Codeweavers has done a lot of work on Wine, which I really appreciate, but I wish they would be much more open. I think there should, at least, be a public database listing all the hacks that are in Crossover. That way, I would know what the heck was going on inside those windowless walls. This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks. Not the Crossover-only ones like sendwndcmd.exe. Or the ones that can't be released because of NDAs. I mean the ones that would improve the vanilla Wine distribution. It seems possible to me that you're not releasing these hacks because they would improve vanilla Wine to the point where nobody would be willing to pay for Crossover anymore. If that is true, it's the other reason that I think Codeweavers is evil. I mean, can't you make enough money on consulting for companies that think that Crossover/Codeweavers is better because it costs more money? If there's no openness about what Crossover is doing to Wine, I just can't trust them to develop it. ~Theodore
On 6/16/15 2:51 PM, Theodore Dubois wrote:
May I suggest you eliminate those hacks by merging them into the Wine codebase?
Most of the hacks would not be accepted into wine - some are simply bad implementations of needed behavior, others are totally bizzare things which are application-specific and should not be included in the main source tree. Over time, the hope (and this does really tend to happen) is that proper, good, quality implementations of the hacks get written and are merged upstream.
This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks.
We always, always release full source when we release a version of CrossOver. Not only for wine, but for other open-source components we use. It is available here: https://www.codeweavers.com/products/faq/source/ If we ever fail to release source when we cut a version of CrossOver, that's a bug and a problem. Tell us about it and we will fix it (it very rarely happens, our release process is pretty smooth). We are obligated by the LGPL to release these sources, so anyone who wants to make a request always can, but they are also always available for download on our website, just like CrossOver itself.
Am 16.06.2015 um 21:56 schrieb Josh DuBois:
On 6/16/15 2:51 PM, Theodore Dubois wrote:
May I suggest you eliminate those hacks by merging them into the Wine codebase?
Most of the hacks would not be accepted into wine - some are simply bad implementations of needed behavior, others are totally bizzare things which are application-specific and should not be included in the main source tree. Over time, the hope (and this does really tend to happen) is that proper, good, quality implementations of the hacks get written and are merged upstream.
This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks.
We always, always release full source when we release a version of CrossOver. Not only for wine, but for other open-source components we use. It is available here:
https://www.codeweavers.com/products/faq/source/
If we ever fail to release source when we cut a version of CrossOver, that's a bug and a problem. Tell us about it and we will fix it (it very rarely happens, our release process is pretty smooth). We are obligated by the LGPL to release these sources, so anyone who wants to make a request always can, but they are also always available for download on our website, just like CrossOver itself.
Fun fact: Such a source distribution of CrossOver was leading to a North Korean Wine: https://www.winehq.org/wwn/383#Examining%20Crosswin While it seems Theodore didn't do his homework and didn't know about that source distribution, one of his point remains: it's not a database, git, or something easily readable, just a blob Oh man, i didn't plan to jump into that "flamewar"... But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". And of course i'm far from perfect, so maybe i just picked the "bad" ones and never had a look at the "good" ones, and of course i also don't always provide a good description... I just wanted to throw in the only thing that bugs me about CW, don't be offended :) Aside from that, i think CW is totally awesome to have for Wine. So my 2c about the wine-staging thing: I think we should integrate them somehow back to winehq. Don't get me wrong, don't just merge the patches :D I mean the whole idea should not be pushed away. Hello! They want to (and do) "mentor" people to get things upstream! Awesome! So what do I mean with integration? Give them some kind of "Approved" stamp, instead of an "Evil" stamp. Simply don't push them out of bugzilla, but sure, we also don't want a flood of new bugs which might not be correctly reported by users... Simply give them a way too handle/keep track/manage/ripe their patchsets at winehq in a way everyone is happy with, maybe accepting git pull request is also a good idea!? Simply give them a place at winehq... And Staging guys, help people with patches on wine-devel, discuss them on #winehackers, and so on I think someone said we should introduce Signed-Off, where is that idea going? I think it sounds like a good idea...
On 17.06.2015 0:07, André Hentschel wrote:
Oh man, i didn't plan to jump into that "flamewar"...
But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". And of course i'm far from perfect, so maybe i just picked the "bad" ones and never had a look at the "good" ones, and of course i also don't always provide a good description... I just wanted to throw in the only thing that bugs me about CW, don't be offended :)
That's a good question, thank you for sharing that, but I don't believe it works like that, there's no internal debates or intensive communication that results in patches stripped from text description. Sometimes when there's a bug report for it people mention it in mail body, sometimes they don't, but later mention a fix on a bug report. So it's up to submitter mostly.
Aside from that, i think CW is totally awesome to have for Wine.
So my 2c about the wine-staging thing: I think we should integrate them somehow back to winehq. Don't get me wrong, don't just merge the patches :D I mean the whole idea should not be pushed away. Hello! They want to (and do) "mentor" people to get things upstream! Awesome! So what do I mean with integration? Give them some kind of "Approved" stamp, instead of an "Evil" stamp. Simply don't push them out of bugzilla, but sure, we also don't want a flood of new bugs which might not be correctly reported by users... Simply give them a way too handle/keep track/manage/ripe their patchsets at winehq in a way everyone is happy with, maybe accepting git pull request is also a good idea!? Simply give them a place at winehq... And Staging guys, help people with patches on wine-devel, discuss them on #winehackers, and so on
Exactly, we have everything for that already, a place to discuss things, irc channel, bugzilla. I don't see why this potential "mentoring" could not happen directly at wine-devel, separate tag for bugzilla reports on patched builds could probably work too I guess. Thing is that I don't remember anyone asking for any of that. (not commenting on pull requests though)
I think someone said we should introduce Signed-Off, where is that idea going? I think it sounds like a good idea...
Am 16.06.2015 um 23:33 schrieb Nikolay Sivov:
On 17.06.2015 0:07, André Hentschel wrote:
Oh man, i didn't plan to jump into that "flamewar"...
But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". And of course i'm far from perfect, so maybe i just picked the "bad" ones and never had a look at the "good" ones, and of course i also don't always provide a good description... I just wanted to throw in the only thing that bugs me about CW, don't be offended :)
That's a good question, thank you for sharing that, but I don't believe it works like that, there's no internal debates or intensive communication that results in patches stripped from text description. Sometimes when there's a bug report for it people mention it in mail body, sometimes they don't, but later mention a fix on a bug report. So it's up to submitter mostly.
I see, maybe I should simply ask the submitter next time...
Le mercredi 17 juin 2015, 00:03:28 André Hentschel a écrit :
Am 16.06.2015 um 23:33 schrieb Nikolay Sivov:
On 17.06.2015 0:07, André Hentschel wrote:
Oh man, i didn't plan to jump into that "flamewar"...
But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". And of course i'm far from perfect, so maybe i just picked the "bad" ones and never had a look at the "good" ones, and of course i also don't always provide a good description... I just wanted to throw in the only thing that bugs me about CW, don't be offended :)> That's a good question, thank you for sharing that, but I don't believe it works like that, there's no internal debates or intensive communication that results in patches stripped from text description. Sometimes when there's a bug report for it people mention it in mail body, sometimes they don't, but later mention a fix on a bug report. So it's up to submitter mostly. I see, maybe I should simply ask the submitter next time...
Hello, I understand that asking for a description is maybe the way forward. How I see commit message is very well described by a Xorg developer: http://who-t.blogspot.be/2009/12/on-commit-messages.html But I see that often when the patch finally gets committed then only the title stays. The text of the commit message has been removed. I presume it is because the message often states something obvious for expert developers with a very good knowledge of the history of the project. But for a non expert who tries to go through the history of code in order to understand it, it doesn't help. So I think that I wouldn't personally dare asking the submitter next time for a better commit message... Cheers, Marc
On Wed, Jun 17, 2015 at 09:44:40PM +0200, Marc Bessières wrote:
I understand that asking for a description is maybe the way forward. How I see commit message is very well described by a Xorg developer: http://who-t.blogspot.be/2009/12/on-commit-messages.html
But I see that often when the patch finally gets committed then only the title stays. The text of the commit message has been removed. I presume it is because the message often states something obvious for expert developers with a very good knowledge of the history of the project. But for a non expert who tries to go through the history of code in order to understand it, it doesn't help. So I think that I wouldn't personally dare asking the submitter next time for a better commit message...
I often try to write good commit messages, but it seems kind of pointless because I know they'll be removed. The messages appear in the wine-patches mailing list archives when people search for them, so I write them anyway. I have no idea where Wine's policy of stripping commit messages comes from and I dislike it. Andrew
On Jun 17, 2015, at 2:59 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
I often try to write good commit messages, but it seems kind of pointless because I know they'll be removed.
They aren't universally removed. Alexandre sometimes edits them down, but most of the commits of my patches have a good chunk of what I wrote. And I'm often pretty verbose. (See, for example, <http://source.winehq.org/git/wine.git/?a=commit;h=792b47ad3b89d51f17ef311ccaa62fc2016af793>.) It's always possible that I'm a special case because a) I mostly work on the Mac driver, about which Alexandre couldn't give two figs; and b) I've worn him down by writing too much too often. ;) I try to help Alexandre by putting the core information that helps future developers (including future me) understand what the patch is for and what it does toward the top and then things like justification or help for reviewers lower down. That way, his edit just amounts to cutting the message off at a certain point.
I have no idea where Wine's policy of stripping commit messages comes from and I dislike it.
As I say, I don't believe there is such a policy. My impression is that you're not the only person who thinks there is, though. Between that and some developers' natural terseness (and, sometimes, assumption that their changes are always self-explanatory), few developers write much. Another problem is that the email submission format doesn't offer a way for the submitter to separate text intended to be part of the permanent commit log from text intended to be merely commentary for consumption at review time. So, Alexandre has to exercise judgment about which parts are which kind and may mis-categorize. -Ken
2015-06-17 22:24 GMT+02:00 Ken Thomases <ken(a)codeweavers.com>:
Another problem is that the email submission format doesn't offer a way for the submitter to separate text intended to be part of the permanent commit log from text intended to be merely commentary for consumption at review time.
Except it does: whatever comment you write after the '---' separator is automatically discarded by git am. Obviously that is meaningful only if you inline the patch, which is a good idea anyway. FWIW I also tend to write commit messages when there is something significant to say and Alexandre often times leaves them in (potentially redacted).
Le mercredi 17 juin 2015, 15:24:56 Ken Thomases a écrit :
On Jun 17, 2015, at 2:59 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote:
I often try to write good commit messages, but it seems kind of pointless because I know they'll be removed.
They aren't universally removed. Alexandre sometimes edits them down, but most of the commits of my patches have a good chunk of what I wrote. And I'm often pretty verbose. (See, for example, <http://source.winehq.org/git/wine.git/?a=commit;h=792b47ad3b89d51f17ef311c caa62fc2016af793>.) It's always possible that I'm a special case because a) I mostly work on the Mac driver, about which Alexandre couldn't give two figs; and b) I've worn him down by writing too much too often. ;)
I try to help Alexandre by putting the core information that helps future developers (including future me) understand what the patch is for and what it does toward the top and then things like justification or help for reviewers lower down. That way, his edit just amounts to cutting the message off at a certain point.
It happens, that the first time I discovered that was with one of your changes :) I was trying to understand: https://bugs.winehq.org/show_bug.cgi?id=30984 which was impacting Gothic 2 for which I was making a new entry in the appdb. The bug said it was a regression introduced by 43984f355a2905e16075a9df3d7fbe463761e853 is the first bad commit commit 43984f355a2905e16075a9df3d7fbe463761e853 Author: Ken Thomases <ken(a)codeweavers.com> Date: Thu May 31 15:33:23 2012 -0500 winex11: Be more conservative when matching keys from built-in layout tables. The commit message is indeed terse :) After some time I found you're original mail which was much more explanatory. https://www.winehq.org/pipermail/wine-patches/2012-May/114666.html
I have no idea where Wine's policy of stripping commit messages comes from and I dislike it.
As I say, I don't believe there is such a policy. My impression is that you're not the only person who thinks there is, though. Between that and some developers' natural terseness (and, sometimes, assumption that their changes are always self-explanatory), few developers write much.
Another problem is that the email submission format doesn't offer a way for the submitter to separate text intended to be part of the permanent commit log from text intended to be merely commentary for consumption at review time. So, Alexandre has to exercise judgment about which parts are which kind and may mis-categorize.
-Ken Isn't the text, that is after the --- and before the diff text, there for that purpose? I've tried to find the documentation, but I didn't succeed. And my git fu is not good enough..
Cheers, Marc
On 16 June 2015 at 23:07, André Hentschel <nerv(a)dawncrow.de> wrote:
But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". Yeah, he probably does. Because the patches are just bloody obvious. Not because we all hold hands at CodeWeavers HQ and discus every step of the development process in secret. Some of us are actually competent developers capable of working on our own.
Am 16.06.2015 um 23:34 schrieb Henri Verbeet:
On 16 June 2015 at 23:07, André Hentschel <nerv(a)dawncrow.de> wrote:
But while I’m at it, Jeremy, the only thing about CW that sometimes bugs me, is that CW devs often send their patches without any description. (Maybe that was also what Theodore means?) Maybe i keep finding only the "bad" ones, but it's always with patches that catch my interest for some reason, and then, no info. And that looks a bit like "AJ already knows what this is about and what it is going to fix, no need to mention it". Yeah, he probably does. Because the patches are just bloody obvious.
They are always so obvious that i want some bloody obvious description about how obvious they are? Yeah, probably!
Not because we all hold hands at CodeWeavers HQ and discus every step of the development process in secret. Some of us are actually competent developers capable of working on our own.
Working on bloody obvious patches? I doubt it... You missed the part about offending...
On 16 June 2015 at 23:50, André Hentschel <nerv(a)dawncrow.de> wrote:
You missed the part about offending...
I read it, but I'm way past that point. At this point, if the relevant project licenses allowed me to prevent anyone involved with wine-staging from using anything I wrote I actually would.
Am 17.06.2015 um 00:25 schrieb Henri Verbeet:
On 16 June 2015 at 23:50, André Hentschel <nerv(a)dawncrow.de> wrote:
You missed the part about offending...
I read it, but I'm way past that point. At this point, if the relevant project licenses allowed me to prevent anyone involved with wine-staging from using anything I wrote I actually would.
First, I don't see me as a staging guy, while i appreciate their work Second, would you share with me/us why you feel that way? What brought you past that point?
On Wed, Jun 17, 2015 at 6:25 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
On 16 June 2015 at 23:50, André Hentschel <nerv(a)dawncrow.de> wrote:
You missed the part about offending...
I read it, but I'm way past that point. At this point, if the relevant project licenses allowed me to prevent anyone involved with wine-staging from using anything I wrote I actually would
I typed out a couple paragraphs just now and then deleted it all.. I'm just going to ask simply .. WHY ? Cheers, Tom
While it seems Theodore didn't do his homework and didn't know about that source distribution, one of his point remains: it's not a database, git, or something easily readable, just a blob
Oh man, i didn't plan to jump into that "flamewar"...
Sadly, we don't have that internally. We don't rebase all our hacks onto Wine every few weeks and get a "clean" set of patches, Alexandre just does merges. There are pros and cons to this system, but I doubt Alexandre will be willing to change it. We file bugs in our internal tracker documenting and explaining each hack, but there are still diffs left over from before we adopted that system, which we don't have documented, and may not understand. Those old diffs can be more of a liability for us, as they're not being tested by the wider community, and just because they helped some application 10 years ago doesn't mean they're not hurting things now.
Simply don't push them out of bugzilla, but sure, we also don't want a flood of new bugs which might not be correctly reported by users...
A "staging" keyword in bugzilla would be a strong indication that wine-staging bugs are desired, but we want to know if there's a difference in behavior between staging and winehq.
Am 16.06.2015 um 23:49 schrieb Vincent Povirk:
While it seems Theodore didn't do his homework and didn't know about that source distribution, one of his point remains: it's not a database, git, or something easily readable, just a blob
Oh man, i didn't plan to jump into that "flamewar"...
Sadly, we don't have that internally. We don't rebase all our hacks onto Wine every few weeks and get a "clean" set of patches, Alexandre just does merges. There are pros and cons to this system, but I doubt Alexandre will be willing to change it.
We file bugs in our internal tracker documenting and explaining each hack, but there are still diffs left over from before we adopted that system, which we don't have documented, and may not understand.
Those old diffs can be more of a liability for us, as they're not being tested by the wider community, and just because they helped some application 10 years ago doesn't mean they're not hurting things now.
Ok. I also don't think they could help Wine and know you'd upstream every non-hack. So those hacks aren't really interesting. Just wanted to try to explain what Theodore said.
Simply don't push them out of bugzilla, but sure, we also don't want a flood of new bugs which might not be correctly reported by users...
A "staging" keyword in bugzilla would be a strong indication that wine-staging bugs are desired, but we want to know if there's a difference in behavior between staging and winehq.
Maybe really something like the regressions page, but for difference between vanilla and staging, and a list of bugs which were only tested on staging and not on vanilla yet... Just an idea I guess more interesting than "wow, it works in staging" would be "ha! staging breaks something, why is that?"...
Hi Theodore, On 06/16/2015 02:51 PM, Theodore Dubois wrote:
First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1].
May I suggest you eliminate those hacks by merging them into the Wine codebase?
Um, I'm afraid you are really not understanding what is happening here. I just pointed out how hard we work to eliminate these hacks. They can't simply be merged; Alexandre will refuse them, that's the point. To eliminate a hack is often months and months of very hard work to implement something 'right'. And the figure I quoted pointed out that we had merged proper fixes, eliminating 4 hacks, in the past six months. So that's probably a man years worth of work in improving Wine that we just finished.
Right now I have a feeling that Wine is wonderful, but Codeweavers is evil. It seems that this feeling is shared by many non-Codeweavers Wine developers. Codeweavers has done a lot of work on Wine, which I really appreciate, but I wish they would be much more open. I think there should, at least, be a public database listing all the hacks that are in Crossover. That way, I would know what the heck was going on inside those windowless walls.
I'm obviously very sad that you perceive us as evil. Do you mind me asking where you got that feeling from? If there is an information source that is revealing all of our evil secrets, I'd like to know about it. <grin>
This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks. Not the Crossover-only ones like sendwndcmd.exe. Or the ones that can't be released because of NDAs. I mean the ones that would improve the vanilla Wine distribution.
All of our Wine code, including our hacks, is publicly released, here: https://www.codeweavers.com/products/faq/source/
It seems possible to me that you're not releasing these hacks because they would improve vanilla Wine to the point where nobody would be willing to pay for Crossover anymore. If that is true, it's the other reason that I think Codeweavers is evil. I mean, can't you make enough money on consulting for companies that think that Crossover/Codeweavers is better because it costs more money?
I'm afraid that a lot of folks have a lot of misconceptions about how much money we make. I wish we had as much as you apparently think we have. The Wine/CrossOver business is not a hugely profitable one. There are far more effective ways that I, and my coworkers, could be making money than what we do. And we do not make money by harming Wine; that holds no appeal for any of us. We try to make money by providing a stable and supported version of Wine. If we're also able to substantially improve Wine, which we often are, we consider that a delightful bonus.
If there's no openness about what Crossover is doing to Wine, I just can't trust them to develop it.
Um, nearly all of the work that we do on CrossOver is done by sending public emails to this mailing list. How is that not open? Or perhaps I should ask - what gave you the impression that we did not develop openly? Cheers, Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-06-16 um 22:28 schrieb Jeremy White:
Um, nearly all of the work that we do on CrossOver is done by sending public emails to this mailing list. How is that not open? Or perhaps I should ask - what gave you the impression that we did not develop openly? I think the problem is that what's being discussed is often not understandable by mere mortals. E.g. Nikolay's Mail says "dwrite: Fix the way drawing effects are reported for inline objects." when users want an answer to the question "Do you work on Office 2013? What is the status of the work? How can I help?"
(Just picking the latest patch from Nikolay as an example. It also applies to my patches, although I do try to give a lot of information what the patch does, even though I know Henri can see it just from the code. I still get questions on IRC and private mails asking if "wined3d: Set the gl resource type in resource_init." improves performance.) Of course any second spent on writing patch descriptions is a second not spent on writing more patches. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVgUbJAAoJEN0/YqbEcdMwLk0QAI50IQZMYYs9uBmD5BB/62vs mRh0RBDa62wkAaBfP5BNarn7gJN2G1MWHfyo7HRjo8kon01xAyl6ggwblFvgHMxr ZLi24KO2z54MYC6rUpHmDfOxdsQz+jbZPaMqopQt/iC4wCAhBgQx/evro8QpKeEo vxEaZ43nTMDQCHLO4OEVHMMVVOG0ulg6yiDpE5WmLyfHrWdiPXl8VXTS3+9U17gc 5lQmkLqbTNNKb27C24Xb+/f9whGc6DPr6PueFoXH+XwDFiP2RR9PrV5xNisYwvHc ejGnybOOEbCdutuJGwAHvWBHEIds6Mw5/RJKsRCKh10VgFz7h/PhS1z8Xa1iyjAW 7l4RhabCUw+WPPruv8xOM5rAeDwdfACluu5cjLxgCBrulbAdzsaaipCDCoEEftd9 fGUKkgVtBKIJDYOI8sgSlMR4FK9G47w8pEfnTcLMJTwJPvwKGfqH/AVvHNyRj8bb AbbZsxceZ89mCplUpOBBn/p9dizCo8Tq0aRgw1mfNDweQGwMFKf8EgB/nHD/sVNR /HbDWfP6aEay2QC1oJhl8JI5B/OtTglpEB4EnCZBVcqxiNWeyT6FamNqpokPO/fL 4QmIAHSqZnDL6qByOE3ixKNc7AR/00L4a2kzX4GtSyrRcxp1nmbLeJJWPKWFnUZ+ fX4+FBcZLgpDVFIwdSlE =hCvc -----END PGP SIGNATURE-----
On Wed, Jun 17, 2015 at 3:51 AM, Theodore Dubois <tblodt(a)icloud.com> wrote:
First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1].
May I suggest you eliminate those hacks by merging them into the Wine codebase?
Right now I have a feeling that Wine is wonderful, but Codeweavers is evil. It seems that this feeling is shared by many non-Codeweavers Wine developers. Codeweavers has done a lot of work on Wine, which I really appreciate, but I wish they would be much more open. I think there should, at least, be a public database listing all the hacks that are in Crossover. That way, I would know what the heck was going on inside those windowless walls.
Disclaimer, I am not a employee of CodeWeavers, never have been never will be! This is just my opinion and it does not reflect the opinion/s of CodeWeavers Inc. Jeremy or Jon please correct me where I'm wrong. CodeWeavers isn't even close to being evil, their actually just the opposite of evil in so many ways. Lets see : WineHQ : They give back all of their good code and even make their hacks available in their CrossOver source release. They pay the hosting and website maintenance for winehq e.g lostwages :) They have been the primary sponsor of every WineConf after the first conference. They will give any wine developer outside of CodeWeavers a free copy of CrossOver Linux or Mac to play with. They setup the 501c none profit and setup everything at the Software Freedom Conservancy so Wine is protected with their legal counsel. CrossOver : They have international pricing that most people are not aware of, so people in developing countries can afford the software! Because they feel that it's better to let the people use the technology, get it out to the users, then to hold out for the last cent, make the highest profit. In a country like where I live I see no way that they are even making a profit, its a charity actually. They actually help people with CrossTie's and support on unsupported software! because they want to make the customer happy. They give promos and discounts to returning customers for their loyalty. At once again CHARITY pricing. OK with that said, wine-staging isn't evil either! they have the best of intentions I believe, and as I see it the problem is proper communication Problems / Solutions : winehq doesn't want wine-staging bugs in their database , simple fix, wine-staging should look into hosting their own bug tracking database and tell users to file bugs here and not their. if your not wanted on IRC or a mailing list fine for talking about staging and not mainline wine then once again, start your own. :( Then the worst case scenario is realized I'm afraid and that being A FORK !!! and who is to blame if it comes to that horrible outcome? I have my opinions, ill let you decide that answer on your own... Acknowledgments : wine-staging makes it possible for the public to test, use the code in their patch set. the wine-staging project is extremely friendly and easy to engage as a developer or end user. wine-staging would make a great wine mentoring project, where new developers could take a look at half baked patches and try to improve them so they could go into mainline wine. Or a new area, feature and do some hand holding to get the process moving along , underway if their not interested in a staging patch to work on.
This may sound unthinkable, but I would also suggest going further and releasing the source code for the hacks. Not the Crossover-only ones like sendwndcmd.exe. Or the ones that can't be released because of NDAs. I mean the ones that would improve the vanilla Wine distribution.
It seems possible to me that you're not releasing these hacks because they would improve vanilla Wine to the point where nobody would be willing to pay for Crossover anymore. If that is true, it's the other reason that I think Codeweavers is evil. I mean, can't you make enough money on consulting for companies that think that Crossover/Codeweavers is better because it costs more money?
The hacks are available as pointed out before. The main selling points for CrossOver is its GUI, point and click installer interface and good support. The hacks are actually a very tiny part of the overall package. The consulting and porting services just help Wine development but I don't believe their anywhere large enough to stand on their own feet, support the company. CrossOver sales are a essential part of the overall business model. See : https://www.codeweavers.com/services/faq/ports/
If there's no openness about what Crossover is doing to Wine, I just can't trust them to develop it.
So your asking a company with 30 employees to feed to turn over their business strategy? Can you lend me the keys to your car? I promise I won't steal it once you fall asleep. ;) Yesterday I was chatting with a CodeWeavers employee about blogging and being more transparent about what goes on behind the walls of the great empire. Would a bi-weekly blog update with updates of whats being tested , worked on, just how many cappuccinos James has knocked off help ?? I have always liked road-maps myself, and others as well I'm sure, as most big companies put out a road-map periodically to say this is what are working on, this is where we would like to go. This is just my idea of better transparency and fun at the same time. Someone pass the pretzels please... Tom
~Theodore
-- Wine is not a conclusion but a process...
On Wed, 17 Jun 2015 21:25:11 +0800 Tom Wickline <twickline(a)gmail.com> wrote:
Problems / Solutions :
winehq doesn't want wine-staging bugs in their database , simple fix, wine-staging should look into hosting their own bug tracking database and tell users to file bugs here and not their.
Wine-staging already has its own bug-tracking database. The problem is that the inexperienced users they are so aggressively marketing to can't reasonably be expected to figure out on their own whether a bug is in mainline Wine or one of the 600+ experimental patches, and simply telling those users to file everything over there will result in bugs that belong here not being reported here. -- Rosanne DiMesio <dimesio(a)earthlink.net>
This strays from the thread topic a bit but I wanted to toss in my thoughts. I believe that Rosanne makes a valid point: It's hard for users to know where to file a bug. I would like to add that users are showing up in all of the derivatives of Wine as reports that "it works here!" without fully understanding what that means or how to explain it (in the worst scenarios, in the best they do it perfectly!). Wine-Staging adds another layer but to the average user it only means their beloved application works somewhere and that's ultimately what led them to Wine & company in the first place. With this, it is difficult for users to know when and where to file a bug or show where it's been fixed and to grasp why it is marked fixed one way but not another. Some obscurity has always been there because of the various projects but Wine-Staging understandably adds to that. The user side is a different part of the conversation but whatever path is taken, it will affect people coming to any of the Wine subsets. I don't know if I disagree with bugs being closed if they mention Wine-Staging as bugs are closed if they mention Winetricks, PlayOnLinux/Mac, CrossOver, WineSkin, WineBottler, and any of the others. It would be gentler to ask, "does this happen in vanilla Wine" and if a person can't test it or doesn't have the skills, redirect them to the appropriate place with closure of the WineHQ bug. I've actually seen similar action to this on every "closed invalid" bug I've reviewed that mentions a third party. Many kudos to the people triaging WineHQ bugs. How much work flow would it add to allow a person to retest the bug in Wine without closing it on the initial pass? And to comment back if they can't? How often would they? I think the Wine-Staging team has done what was requested and has made it possible to tell if output/logging comes from them. Running a Windows application out of Wine-Staging right now, the first two lines in the output are: fixme:winediag:start_process Wine Staging 1.7.45 is a testing version containing experimental patches. fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org). Thank you. And my favorite comment to this is: ”Ack, you're right. Mea culpa. Apparently the giant "this is staging" warnings were being squelched on my end. Will repost there." I'm not sure if there's more that can be done to distinguish when an application is running in Wine-Staging versus the others. How much more do we need in log files? The hard messaging I see about Wine-Staging is on this page: "Fedora for example ditched their regular Wine version and replaced it with Wine Staging." In the threads about Wine-Staging on wine-devel, it's apparent that the Fedora team was discouraged from doing this but on the Wine-Staging landing page it feels more like a selling point. I understand the importance of stating the above in a positive way but I wonder if this statement isn't a little over the top. If I could wave my magic wand, I would wish for some sort of peace with Wine-Staging because they have done some very positive things: * There are (or seem to be) more active responses to queries on wine-devel, isn't that what everyone wanted? * There are patches that have made it into Wine with assistance * There are people testing out patches that are not yet in Wine but need review (and it was my understanding that it was difficult to get people to test single patches) * There is a growing community using Wine (regardless of what flavor) Wine-Staging is no more evil than the rest of us and at least from my point of view, we're all here to make a positive difference in Wine. Many thanks for your time, Caron -----Original Message----- From: wine-devel [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Rosanne DiMesio Sent: Wednesday, June 17, 2015 10:13 AM To: wine-devel(a)winehq.org Subject: Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.) On Wed, 17 Jun 2015 21:25:11 +0800 Tom Wickline <twickline(a)gmail.com> wrote:
Problems / Solutions :
winehq doesn't want wine-staging bugs in their database , simple fix, wine-staging should look into hosting their own bug tracking database and tell users to file bugs here and not their.
Wine-staging already has its own bug-tracking database. The problem is that the inexperienced users they are so aggressively marketing to can't reasonably be expected to figure out on their own whether a bug is in mainline Wine or one of the 600+ experimental patches, and simply telling those users to file everything over there will result in bugs that belong here not being reported here. -- Rosanne DiMesio <dimesio(a)earthlink.net>
On 06/17/2015 12:05 PM, Caron Wills wrote:
The hard messaging I see about Wine-Staging is on this page:
"Fedora for example ditched their regular Wine version and replaced it with Wine Staging."
In the threads about Wine-Staging on wine-devel, it's apparent that the Fedora team was discouraged from doing this but on the Wine-Staging landing page it feels more like a selling point. I understand the importance of stating the above in a positive way but I wonder if this statement isn't a little over the top.
Their statement is indeed flamboyant and it is not entirely accurate. This is the first time I have seen it. Fedora applied wine-staging to be able to use "pipelight", which allows users to view Netflix (a video streaming service). I was initially against it, but Andreas decided it was worth adding. I'm CC'ing Sebastian to update their page. We ship users' bug reports off to wine-staging before they make it here. Thanks, Michael Fedora Maintainer
On Wed, Jun 17, 2015 at 11:05 AM, Caron Wills <caron(a)codeweavers.com> wrote:
I believe that Rosanne makes a valid point: It's hard for users to know where to file a bug.
We would be open to having a separate product on WineHQ so that people can easily move a bug to being our responsibility. We originally decided for a separate bug tracker because after talking to several people, we got the impression that they would prefer this solution. Its really unfortunate when people are still reporting bugs at the wrong place, especially because we have this huge Wine Staging warning on process startup and replaced all bug reporting urls (manpage and crash dialog).
... In the threads about Wine-Staging on wine-devel, it's apparent that the Fedora team was discouraged from doing this but on the Wine-Staging landing page it feels more like a selling point. I understand the importance of stating the above in a positive way but I wonder if this statement isn't a little over the top.
I think that’s a fair point, how would you feel about "We provide packages for a lot of distributions and some of them even include Wine Staging directly into their repositories.” ? (no next sentence)
... Wine-Staging is no more evil than the rest of us and at least from my point of view, we're all here to make a positive difference in Wine.
At work I recently learned about the volleyball concept of a Libero, whose role is to make sure that no ball touches the ground. I feel that wine-staging has a similar purpose, our role is to make sure that no patch gets left behind and the knowledge behind it gets lost. Patches get forgotten for a variety of reasons (lack of time, lack of interest, frustration with our high quality standards, etc.) and I think we serve an important role in getting these patches tested, vetted, fixed, and upstreamed. It really concerns me that people are upset with what we’ve been doing, as I feel that we provide a vital role in the Wine community. The only thing that I can think of to explain this situation is that at some point there’s been some sort of miscommunication. I really appreciate the concrete suggestion here, if anyone has other concerns that they’d like to address with us then I’d be happy to hear them. Best, Erich
Am 17.06.2015 um 20:13 schrieb Erich E. Hoover:
I think that’s a fair point, how would you feel about "We provide packages for a lot of distributions and some of them even include Wine Staging directly into their repositories.” ? (no next sentence)
I updated the whole paragraph and removed this sentence. In case there are more things someone doesn't feel comfortable with, the website is available via git: https://github.com/wine-compholio/website Feel free to suggest a patch. Regards, Michael
Thank you for the consideration and the fast response regarding the wording change. I truly appreciate it. -Caron -----Original Message----- From: wine-devel [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Michael Müller Sent: Wednesday, June 17, 2015 1:37 PM To: Erich E. Hoover; Michael Cronenworth; wine-devel(a)winehq.org Subject: Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.) Am 17.06.2015 um 20:13 schrieb Erich E. Hoover:
I think that’s a fair point, how would you feel about "We provide packages for a lot of distributions and some of them even include Wine Staging directly into their repositories.” ? (no next sentence)
I updated the whole paragraph and removed this sentence. In case there are more things someone doesn't feel comfortable with, the website is available via git: https://github.com/wine-compholio/website Feel free to suggest a patch. Regards, Michael
On Wed, Jun 17, 2015 at 1:13 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote:
We would be open to having a separate product on WineHQ so that people can easily move a bug to being our responsibility.
My problem with a separate product is that it means you have separate components as well, and thus a search for the "gdiplus" component won't show those bugs. Personally, I want to see the bugs in the components I'm interested in even if they may be specific to wine-staging. For this reason, I would rather have a keyword (meaning: might require wine-staging to reproduce). Some developers may only be interested in bugs they know are in winehq, or latest winehq. It can certainly be frustrating when you use latest winehq as a baseline, and you find that the bug only happens in earlier versions or some derivative. But I feel like retesting can be (but doesn't always have to be) part of the debugging process, and bugs can still be useful without that information.
Jeremy or Jon please correct me where I'm wrong.
Righto.
CodeWeavers isn't even close to being evil, their actually just the opposite of evil in so many ways.
Too tempting to make a joke here... <evil grin>
Lets see :
WineHQ : They have been the primary sponsor of every WineConf after the first conference.
Not quite accurate. We have funded a few of the ones held in Minnesota, and CodeWeavers has historically sponsored the Saturday dinner (except for Stuttgart, when Michael bought <grin>). But the Wine fund is in good shape and can pay it's own way now, so Wine itself has paid for the last few.
They setup the 501c none profit and setup everything at the Software Freedom Conservancy so Wine is protected with their legal counsel.
Just to clarify - I, as a private citizen, set up the mechanisms to collect money from winehq (fun fact: for a while, it went to my private bank account <grin>), and Alexandre and I, as private citizens, were the ones that transferred those funds to Conservancy, and asked Conservancy to provide a holding organization for Wine. And more recently, Austin, Marcus and Michael Stefaniuc have agreed to help monitor and disburse funds. And to be even more clear, the credit for the bulk of that hard work goes to the Conservancy, and to Bradley Kuhn in particular. CodeWeavers had nothing to do with it, although I recognize that subtlety is hard to appreciate. Cheers, Jeremy
Folks, [I wasn't going to say anything in this thread until I felt that I had something insightful to say, as is my usual way of communicating. But I realize that my communication style is a part of the problem, and I'm trying to fix that. So here we go ;-] There are undeniably a number of things that we as a group, and myself as the maintainer, could be doing better. A lot of us have been doing this for a long time, and are taking many things for granted. Because of that, it has become too easy to dismiss new ideas and different ways of thinking. Personally I've also been fairly distracted lately, with my move to Japan and my work on Android support, and I haven't been able to devote enough attention to Wine. I'm also hoping to change that. 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. I'll then summarize the suggestions so that we can discuss our options. And by the time we meet at WineConf, we can hopefully agree on what changes we want to make, and start implementing them. Then we can all make up over a beer ;-) -- Alexandre Julliard julliard(a)winehq.org
On Thu, Jun 18, 2015 at 2:08 AM, Alexandre Julliard wrote:
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.
Sorry if this starts in a new thread; I had stopped emails from the list for a while so I'm replying through the archive. I haven't really contributed to the Wine project since working on the wiki a couple years back, but I thought I might have some useful input. For several years, I've flirted at times with contributing code to the core project. I never have, for personal reasons more than anything; other things just pop up in life. From what I've seen though, you're all definitely very talented and sharp, and your communication skills are actually pretty good, even if messages are terse at times. But I have noticed several instances of what, I think, might be the project's central problem. To put it in parable, the Wine community (and not just the programmers) seems like a team of strong, speedy soccer players with great footwork and stamina... yet everyone just swarms the ball like in a youth league. I hope nobody takes offense, but that's the quickest way I could explain it. Sometimes people work on the same problem, sometimes separate concerns, but at least from the outside, there doesn't seem to be much deep coordination. If I can toss out ideas, I think the community could really use more of two things: strategy and logistics. I know there's the grand mission statement to become everyone's favorite Windows API implementation, even Bill Gates' ;) And there are the release criteria. A strategy though isn't just about setting goals, but also committing people and resources to those goals after seeing things clearly and thinking ahead some. I don't know if a sign-off system or making peace with wine-staging would be part of this, but if Alexandre personally wanted to try something different, my first thought is taking an approach that's a little less field officer and a little more grand vizier. Now the logistics thing is interesting because I don't think that's a group issue so much as a material one. I could be very wrong here since I don't have a ton of experience, especially with large projects, but I wonder if the project's ancillary tools and documentation are rich enough. For a code-base as large as Wine's, maybe a broader ecosystem of tools could make a big difference. Beyond making the project more accessible to new developers, it might help the veterans step on each other's toes less when different philosophies spring up (like the wine-staging debate). I know in my case, all the little catches in the build process and changes to my system that need to be managed (especially on an amd64 distro) are discouraging. I'm sure I could work past them if it became a major hobby of mine, but at this point in my life, it's enough to change my calculus about actively testing or developing patches. Even if you're willing to go through the manual tedium necessary to start testing, it's not easy to find simple answers to problems that pop up because the documentation is scattered about and contradictory. I hope I haven't come across as presumptuous; Wine is a great project with a lot of great people. I just noticed a pattern in all the hurdles I hit while trying to become more involved, and they seem to match up with what others are describing here. - Kyle
participants (20)
-
Alexandre Julliard -
Andrew Eikum -
André Hentschel -
Caron Wills -
Erich E. Hoover -
Henri Verbeet -
Jeremy White -
Josh DuBois -
Ken Thomases -
Kyle Auble -
Marc Bessières -
Matteo Bruni -
Michael Cronenworth -
Michael Müller -
Nikolay Sivov -
Rosanne DiMesio -
Stefan Dösinger -
Theodore Dubois -
Tom Wickline -
Vincent Povirk