Wine staging tree
Hi, since I already revealed our staging tree idea in a mail which I accidentally send to wine-devel, I think it is time to explain the whole idea. Before you start complaining, please carefully read the whole mail, and especially note that we're in no way trying to compete with vanilla Wine (which seems to be the main counter-argument I've heard so far). Wine is a huge project and it is easy to introduce new regressions or to have mistakes in your patches. For this reason all patches need to be accepted by AJ to keep a good code quality. Nevertheless it is not unusual that patches drop out of the list because they don't get any attention or contributors get frustrated because sending try XX is a slow process of gaining feedback. Just to be clear: I think its absolutely essential that Wine has a stable and very well tested code base, so I'm _not_ suggesting to change the submission rules. Nevertheless its sometimes impossible to test a patch, without having some user feedback. Besides that, there is a huge gap between Wine user perspective and Wine developer perspective: Users sometimes would prefer to use an early beta version of a patch (which might not be the perfect solution, but the application at least works), whereas developers prefer a well-tested and 100% correct solution. For this reason we converted wine-compholio (which was previously used to provide patches for Silverlight / Pipelight) to some kind of staging tree. We add patches there which may not be yet be completely ready for wine-patches, for example some features are not fully implemented yet or need additional testing. This makes it possible for other developers to take a look at them before they reach wine-patches and they can give you feedback and point out possible mistakes. This is especially suited for new contributors. Just think about all the GSoC students, which spend months to implement new features, and at the end the code is lost and not really maintained anymore, because it wasn't in a perfect shape yet to go upstream. That shouldn't happen at my opinion. Besides the possibility of getting feedback, your patches will also be tested by regular users to reveal regressions. We follow the same release cycle as Wine (with usually 1 days offset) and provide prebuilt packages for: Ubuntu, Arch Linux, Debian, OpenSUSE, Fedora, Mageia 4 and there are also 3rd party builds for other distributions like Slackware. Fedora directly integrates our patches into their wine package. Some users also prefer wine-compholio since they get patches for their software earlier, and developers have the advantage to know about regressions faster. Although being a staging tree, we don't want to break too much stuff for our users and therefore do not accept any hacks like PlayOnLinux. If there is a highly demanded application with a known workaround, we may consider making an exception - but we _definitely_ don't want to end up like PlayOnLinux ;-). We always try to find a compromise between the user and the developers perspective. However, If you introduce regressions and don't fix them till the next release we may consider dropping the patches again. Since our aim is to get patches upstream, our repo does not contain the whole wine source code but only patches to make this task easy. We also use a sophisticated patch system which creates a Makefile that automatically figures out dependencies between patchsets and prevents adding patches that do not apply, but explaining all that would be too much for this mail ;-). If you think this might be a great idea and/or you want to make use of it, you can find all required information at: https://github.com/compholio/wine-compholio https://github.com/compholio/wine-compholio/blob/master/DEVELOPER.md We also try to improve existing patches from bugs or patches which did not get upstream, so don't be surprised if you find one your patches in our repo. ;-) There is currently no mailing list for suggesting patches (as mentioned at the beginning our original plan was to wait a bit more, before officially announcing this idea), but you can either talk to us in #wine-compholio on FreeNode or open a bug report on github to propose patches. We neither want to prevent anybody from sending their patches upstream, nor to be a competitor to Wine, we just want to give some optional extra help for both developers and users. Instead of having lots of private developer work-in-progress branches, this makes it possible to create a combined version, and users get an easy way to test fixes without compiling wine on their own (for example if you have a fix for a bug and want other people to verify whether it solves the problem for them). Regards, Michael
Hi Michael, Thanks for your long email about some sort of wine 'staging' project. I understand what you are you trying to accomplish, but I have various concerns, which I will share below. The initial motivation for this project seems to be to allow users to test patches at an earlier stage. It may allow users to run their app sooner. For developers it can give their code more testing, which I agree can be useful. My main concern is that the quality of a lot of the patches is unfortunately so-so, with various lose ends and side effects various developers can't oversee. AJ is right to reject such patches. This can be a hinder for a new developers, it is not always as easy to get feedback and yes some mentoring for new developers can really help. Over the years there have been various projects in different forms like PlayOnLinux to allow users to run Wine with non-upstreamed patches. As you know the main concern of PlayOnLinux is that due to all the patching it is not vanilla Wine anymore, but a 'tainted version'. This makes us typically reject bug reports, because we don't know what code went in it, which can waste a developers time. No matter how good the intentions are to do a better job than PlayOnLinux, I'm skeptical. I actually went over several of the patches in the repo and various of them look incorrect. I understand that they may make app Z work and while they may not always be as evil as PlayOnLinux-style hacks, I still don't want them to be out in the public. In my opinion any tainted Wine is bad for Wine developers. Yes, user may test your new patch, but I expect to get a lot of issues back due to other incomplete patches with side effects. In an ideal world there would be no need for your project, because all patches make it upstream quickly. I think the discussion should be more on how to get closer and closer to this situation. I think it should more be found in mentoring and providing more feedback. Since Wine is an open source project, nobody forbids you from working on your customized Wine. Providing builds to users to try it is fine with me, but clearly don't mark it as the official Wine, but as you already doing by calling it 'wine-compholio'. What does really scare me are the Fedora Wine builds. After you said that they incorporate your changes, I checked the rpm and indeed it uses 150+ custom patches from your repo. In my opinion, distro packages need to be as vanilla as possible to prevent the PlayOnLinux-like bug rejection issues. Sometimes build system change or some minor change is needed, but such an amount of patches is not justified. Myself I don't have much time to work on Wine anymore these days, but if I got bugs from Fedora users, I would reject their bugs. I hope other Wine developers would really do the same, because the packages clearly can't be trusted. Overall I know the intentions are good to allow users to test new code sooner and allow developers to get their stuff test sooner. I'm really skeptical about the benefit for developers due to the tainted Wine builds. I think overall it may actually be more negative than positive for Wine. Thanks, Roderick On Wed, Oct 1, 2014 at 11:27 AM, Michael Müller <michael(a)fds-team.de> wrote:
Hi,
since I already revealed our staging tree idea in a mail which I accidentally send to wine-devel, I think it is time to explain the whole idea. Before you start complaining, please carefully read the whole mail, and especially note that we're in no way trying to compete with vanilla Wine (which seems to be the main counter-argument I've heard so far).
Wine is a huge project and it is easy to introduce new regressions or to have mistakes in your patches. For this reason all patches need to be accepted by AJ to keep a good code quality. Nevertheless it is not unusual that patches drop out of the list because they don't get any attention or contributors get frustrated because sending try XX is a slow process of gaining feedback. Just to be clear: I think its absolutely essential that Wine has a stable and very well tested code base, so I'm _not_ suggesting to change the submission rules.
Nevertheless its sometimes impossible to test a patch, without having some user feedback. Besides that, there is a huge gap between Wine user perspective and Wine developer perspective: Users sometimes would prefer to use an early beta version of a patch (which might not be the perfect solution, but the application at least works), whereas developers prefer a well-tested and 100% correct solution.
For this reason we converted wine-compholio (which was previously used to provide patches for Silverlight / Pipelight) to some kind of staging tree. We add patches there which may not be yet be completely ready for wine-patches, for example some features are not fully implemented yet or need additional testing. This makes it possible for other developers to take a look at them before they reach wine-patches and they can give you feedback and point out possible mistakes. This is especially suited for new contributors. Just think about all the GSoC students, which spend months to implement new features, and at the end the code is lost and not really maintained anymore, because it wasn't in a perfect shape yet to go upstream. That shouldn't happen at my opinion.
Besides the possibility of getting feedback, your patches will also be tested by regular users to reveal regressions. We follow the same release cycle as Wine (with usually 1 days offset) and provide prebuilt packages for: Ubuntu, Arch Linux, Debian, OpenSUSE, Fedora, Mageia 4 and there are also 3rd party builds for other distributions like Slackware. Fedora directly integrates our patches into their wine package. Some users also prefer wine-compholio since they get patches for their software earlier, and developers have the advantage to know about regressions faster.
Although being a staging tree, we don't want to break too much stuff for our users and therefore do not accept any hacks like PlayOnLinux. If there is a highly demanded application with a known workaround, we may consider making an exception - but we _definitely_ don't want to end up like PlayOnLinux ;-). We always try to find a compromise between the user and the developers perspective. However, If you introduce regressions and don't fix them till the next release we may consider dropping the patches again. Since our aim is to get patches upstream, our repo does not contain the whole wine source code but only patches to make this task easy. We also use a sophisticated patch system which creates a Makefile that automatically figures out dependencies between patchsets and prevents adding patches that do not apply, but explaining all that would be too much for this mail ;-).
If you think this might be a great idea and/or you want to make use of it, you can find all required information at:
https://github.com/compholio/wine-compholio https://github.com/compholio/wine-compholio/blob/master/DEVELOPER.md
We also try to improve existing patches from bugs or patches which did not get upstream, so don't be surprised if you find one your patches in our repo. ;-) There is currently no mailing list for suggesting patches (as mentioned at the beginning our original plan was to wait a bit more, before officially announcing this idea), but you can either talk to us in #wine-compholio on FreeNode or open a bug report on github to propose patches.
We neither want to prevent anybody from sending their patches upstream, nor to be a competitor to Wine, we just want to give some optional extra help for both developers and users. Instead of having lots of private developer work-in-progress branches, this makes it possible to create a combined version, and users get an easy way to test fixes without compiling wine on their own (for example if you have a fix for a bug and want other people to verify whether it solves the problem for them).
Regards, Michael
On Wed, Oct 1, 2014 at 9:59 PM, Roderick Colenbrander < thunderbird2k(a)gmail.com> wrote:
No matter how good the intentions are to do a better job than PlayOnLinux, I'm skeptical. I actually went over several of the patches in the repo and various of them look incorrect. I understand that they may make app Z work and while they may not always be as evil as PlayOnLinux-style hacks, I still don't want them to be out in the public. In my opinion any tainted Wine is bad for Wine developers. Yes, user may test your new patch, but I expect to get a lot of issues back due to other incomplete patches with side effects.
In an ideal world there would be no need for your project, because all patches make it upstream quickly. I think the discussion should be more on how to get closer and closer to this situation. I think it should more be found in mentoring and providing more feedback.
Since Wine is an open source project, nobody forbids you from working on your customized Wine. Providing builds to users to try it is fine with me, but clearly don't mark it as the official Wine, but as you already doing by calling it 'wine-compholio'.
What does really scare me are the Fedora Wine builds. After you said that they incorporate your changes, I checked the rpm and indeed it uses 150+ custom patches from your repo. In my opinion, distro packages need to be as vanilla as possible to prevent the PlayOnLinux-like bug rejection issues. Sometimes build system change or some minor change is needed, but such an amount of patches is not justified. Myself I don't have much time to work on Wine anymore these days, but if I got bugs from Fedora users, I would reject their bugs. I hope other Wine developers would really do the same, because the packages clearly can't be trusted.
I'll note that, in Ubuntu, I've been including a few of these "distro-specific" patches (accepted stuff like font types) for a while, but also the PulseAudio series of patches by Maarten Lankhorst. The reason is that, at the end of the day, WinePulse is needed for users (some of them using Wine professionally), and that if I had to wait for a properly Pulse-supporting upstream sound driver I'd be leaving a million users hanging for 4 years counting. That said, I don't have the skill or time to vet the random patches going into the Wine-compholio branch, and think their separate PPA (deriving from my packages, I believe) is a perfectly reasonable solution. Users can try stable Wine included with Ubuntu, then beta Wine from my PPA, then compholio Wine if they have reason to think that might work for their app. Thanks, Scott Ritchie
Hi Roderick, On 02.10.2014 06:59, Roderick Colenbrander wrote:
Hi Michael,
Thanks for your long email about some sort of wine 'staging' project. I understand what you are you trying to accomplish, but I have various concerns, which I will share below.
The initial motivation for this project seems to be to allow users to test patches at an earlier stage. It may allow users to run their app sooner. For developers it can give their code more testing, which I agree can be useful.
My main concern is that the quality of a lot of the patches is unfortunately so-so, with various lose ends and side effects various developers can't oversee. AJ is right to reject such patches. This can be a hinder for a new developers, it is not always as easy to get feedback and yes some mentoring for new developers can really help.
As Michael already said in his previous mail, rejecting patches if they still contain flaws, is the right and the only way to do it. And of course having a more active mailing list would speed up the process of upstreaming stuff. Nevertheless, this has nothing to do with "new developers", we know _several_ examples of long-contributing developers (don't want to point at anyone...) who have the same impression, that just sending patches and getting it accepted _or_ useful feedback for improvements just doesn't work in most cases on wine-devel. At my opinion it mainly has to do with the interest of developers to get specific issues fixed. If there is not enough interest, then a lot of useful work might just not get enough attention, and is lost, even if it was for example actually done by a _payed_ GSoC student. Even if the implementation is _not used at all_ for the final version, it is still useful to see the ideas of other developers, or for example included testcases, to confirm tha t the "better" implementation is also correct. Developing is a process of improving a code over and over again, and there is no way to do that in an official repository. I personally like the current approach of shared repo, and it is not really that different from all the private developer repositories, which are also included in various Wine builds (wine-multimedia, wine-csmt, ...).
Over the years there have been various projects in different forms like PlayOnLinux to allow users to run Wine with non-upstreamed patches. As you know the main concern of PlayOnLinux is that due to all the patching it is not vanilla Wine anymore, but a 'tainted version'. This makes us typically reject bug reports, because we don't know what code went in it, which can waste a developers time.
We are aware of that, and thats perfectly fine (more details below).
No matter how good the intentions are to do a better job than PlayOnLinux, I'm skeptical. I actually went over several of the patches in the repo and various of them look incorrect. I understand that they may make app Z work and while they may not always be as evil as PlayOnLinux-style hacks, I still don't want them to be out in the public. In my opinion any tainted Wine is bad for Wine developers. Yes, user may test your new patch, but I expect to get a lot of issues back due to other incomplete patches with side effects.
"various look incorrect" <- Isn't that exactly what we were talking about? ;) If you spotted an error immediately while taking a short look, why don't you report it to us? If you mean one of the few patches, where we're not using an optimal solution yet, feel free to suggest a better one. Not sure which patches you were looking at, but most of them are correct, and might only need minor cleanup. We wouldn't add any patches where we are aware of, that it will have negative side affects for other applications. For most patches we also spend a lot of time discussing the possible effects before we come to a conclusion, if it should be added or not.
In an ideal world there would be no need for your project, because all patches make it upstream quickly. I think the discussion should be more on how to get closer and closer to this situation. I think it should more be found in mentoring and providing more feedback.
Well, feel free to provide concrete suggestions if you have a better idea how to solve that. ;)
Since Wine is an open source project, nobody forbids you from working on your customized Wine. Providing builds to users to try it is fine with me, but clearly don't mark it as the official Wine, but as you already doing by calling it 'wine-compholio'.
What does really scare me are the Fedora Wine builds. After you said that they incorporate your changes, I checked the rpm and indeed it uses 150+ custom patches from your repo. In my opinion, distro packages need to be as vanilla as possible to prevent the PlayOnLinux-like bug rejection issues. Sometimes build system change or some minor change is needed, but such an amount of patches is not justified. Myself I don't have much time to work on Wine anymore these days, but if I got bugs from Fedora users, I would reject their bugs. I hope other Wine developers would really do the same, because the packages clearly can't be trusted.
Please note that it was never our idea to get these patches into regular distribution packages. In case of Fedora the packager contacted us, and even proceeded after both Michael and I told him about the possible consequences, and that we personally don't recommend to do that. I will not cite anything here, as this was discussed in private mail contact, but I think the Fedora guys are totally aware that each bug report by Fedora users can get rejected without a comment. Recently I also opened a bug report, since I would really prefer to have a clear statement somewhere, that people shouldn't report bugs to winehq, see: https://bugzilla.redhat.com/show_bug.cgi?id=1147271
Overall I know the intentions are good to allow users to test new code sooner and allow developers to get their stuff test sooner. I'm really skeptical about the benefit for developers due to the tainted Wine builds. I think overall it may actually be more negative than positive for Wine.
I don't think so. The question is just what is better: Having users reporting the same well-known issues over and over again (have to be identified as duplicates, also wastes time!), or probably a follow-up/regression issue which cannot be reproduced with vanilla Wine (bug reports can be easily closed, when error description doesn't match on developer machine). As you might know, the second problem already applies to a _huge_ amount of bugs, since users already use various (often unnecessary) winetricks recipes without knowing what they do, or report bugs when using PlayOnLinux or at least wine-multimedia (= _every_ Ubuntu user). Unless Wine reached a state, where it works out of the box with almost every app, there will always be a specific part of users with patched/modified versions - our approach is just a bit more combined and organized than some of the previous attempts, by reducing this to work-in-progress solutions. ;) If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches".
Thanks, Roderick
Regards, Sebastian
On Thu, 02 Oct 2014 12:51:19 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote:
If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches".
We shouldn't have to do that. Users have the right to install whatever they want on their computers, but they also have the right to be fully informed of the consequences of their decision. That single sentence on your web page is not adequate warning. We've already had one invalid bug filed by a Fedora user who clearly didn't know he was using an unsupported build. The winepulse driver in the Ubuntu packages includes a console message explicitly telling users it is not supported by the Wine Project, and telling them where they should report problems with it. Your build should do something similar. This goes beyond bugzilla. Users of patched versions of Wine also cannot file AppDB test reports or ask for help on our forum. Please make that much clearer to your users. -- Rosanne DiMesio <dimesio(a)earthlink.net>
Am 02.10.2014 um 16:21 schrieb Rosanne DiMesio:
We shouldn't have to do that.
Users have the right to install whatever they want on their computers, but they also have the right to be fully informed of the consequences of their decision. That single sentence on your web page is not adequate warning. We've already had one invalid bug filed by a Fedora user who clearly didn't know he was using an unsupported build.
The winepulse driver in the Ubuntu packages includes a console message explicitly telling users it is not supported by the Wine Project, and telling them where they should report problems with it. Your build should do something similar.
This goes beyond bugzilla. Users of patched versions of Wine also cannot file AppDB test reports or ask for help on our forum. Please make that much clearer to your users.
We always call our wine version wine-compholio so that it should be clear that it is not vanilla wine. I am also not aware of any bug reports opened by wine-compholio users (except Fedora, see below). We may consider adding a similar warning like Pulseaudio if this is going to be a problem. The only difference is Fedoras Wine build, but unlike you might think, we did not ask them to include our patches. They contacted us since they wanted to include the Silverlight patches to support Pipelight, but against our recommendation to either only include the Silverlight related patches or to provide a separate package, they decided to include them all into their main wine package. As Sebastian wrote, we already opened a bug report for this in their bug tracker. Regards, Michael
On Thu, 02 Oct 2014 16:57:24 +0200 Michael Müller <michael(a)fds-team.de> wrote:
We may consider adding a similar warning like Pulseaudio if this is going to be a problem.
Please do so, because it is going to be a problem. The reality is users don't always tell us they are using an unsupported build; many of them don't really know what they are using. Those of us who provide user support need a way to immediately identify your build so we can direct your users to your support channels. Asking everyone to run wine --patches (which is what we would have to do without such a warning) is unreasonable. I do realize the Fedora situation is not your fault. But IMO, it illustrates why you do need to put the warning in your build. You have no way of stopping other packagers from doing the same. -- Rosanne DiMesio <dimesio(a)earthlink.net>
On 02.10.2014 17:29, Rosanne DiMesio wrote:
On Thu, 02 Oct 2014 16:57:24 +0200 Michael Müller <michael(a)fds-team.de> wrote:
We may consider adding a similar warning like Pulseaudio if this is going to be a problem.
Please do so, because it is going to be a problem. The reality is users don't always tell us they are using an unsupported build; many of them don't really know what they are using. Those of us who provide user support need a way to immediately identify your build so we can direct your users to your support channels. Asking everyone to run wine --patches (which is what we would have to do without such a warning) is unreasonable.
I do realize the Fedora situation is not your fault. But IMO, it illustrates why you do need to put the warning in your build. You have no way of stopping other packagers from doing the same.
I've just added a patch to show such a warning similar to winepulse and modified the wine version string by appending '(Compholio)', as suggested by Austin. It will be part of Wine-Compholio >= 1.7.28. Hopefully this will calm down all people who are concerned about invalid bug reports. Nevertheless, from my own experience of working on specific bugs, I don't think it will have any significant effect: Users will _never_ be able to provide fully detailed information to ensure the issue can be reproduced. Users without any visible sign of a patched version might use PlayOnLinux (no changed --version), might use a self-build version with missing dependencies or wrong gcc version, might use a huge amount of winetricks recipes, all applied on top of each other, might use Ubuntu Wine (containing wine-multimedia, which is _more_ than just a minimal patchset for PulseAudio support), might have broken drivers, ... Regards, Sebastian
On Oct 2, 2014 5:21 PM, "Sebastian Lackner" <sebastian(a)fds-team.de> wrote:
Hi Roderick,
On 02.10.2014 06:59, Roderick Colenbrander wrote:
Hi Michael,
Thanks for your long email about some sort of wine 'staging' project. I understand what you are you trying to accomplish, but I have various concerns, which I will share below.
The initial motivation for this project seems to be to allow users to
test
patches at an earlier stage. It may allow users to run their app sooner. For developers it can give their code more testing, which I agree can be useful.
My main concern is that the quality of a lot of the patches is unfortunately so-so, with various lose ends and side effects various developers can't oversee. AJ is right to reject such patches. This can be a hinder for a new developers, it is not always as easy to get feedback and yes some mentoring for new developers can really help.
As Michael already said in his previous mail, rejecting patches if they still contain flaws, is the right and the only way to do it. And of course having a more active mailing list would speed up the process of upstreaming stuff. Nevertheless, this has nothing to do with "new developers", we know _several_ examples of long-contributing developers (don't want to point at anyone...) who have the same impression, that just sending patches and getting it accepted _or_ useful feedback for improvements just doesn't work in most cases on wine-devel. At my opinion it mainly has to do with the interest of developers to get specific issues fixed. If there is not enough interest, then a lot of useful work might just not get enough attention, and is lost, even if it was for example actually done by a _payed_ GSoC student. Even if the implementation is _not used at all_ for the final version, it is still useful to see the ideas of other developers, or for example included testcases, to confirm tha t the "better" implementation is also correct. Developing is a process of improving a code over and over again, and there is no way to do that in an official repository. I personally like the current approach of shared repo, and it is not really that different from all the private developer repositories, which are also included in various Wine builds (wine-multimedia, wine-csmt, ...).
Over the years there have been various projects in different forms like PlayOnLinux to allow users to run Wine with non-upstreamed patches. As
you
know the main concern of PlayOnLinux is that due to all the patching it is not vanilla Wine anymore, but a 'tainted version'. This makes us typically reject bug reports, because we don't know what code went in it, which can waste a developers time.
We are aware of that, and thats perfectly fine (more details below).
No matter how good the intentions are to do a better job than
PlayOnLinux,
I'm skeptical. I actually went over several of the patches in the repo and various of them look incorrect. I understand that they may make app Z work and while they may not always be as evil as PlayOnLinux-style hacks, I still don't want them to be out in the public. In my opinion any tainted Wine is bad for Wine developers. Yes, user may test your new patch, but I expect to get a lot of issues back due to other incomplete patches with side effects.
"various look incorrect" <- Isn't that exactly what we were talking about? ;) If you spotted an error immediately while taking a short look, why don't you report it to us? If you mean one of the few patches, where we're not using an optimal solution yet, feel free to suggest a better one. Not sure which patches you were looking at, but most of them are correct, and might only need minor cleanup. We wouldn't add any patches where we are aware of, that it will have negative side affects for other applications. For most patches we also spend a lot of time discussing the possible effects before we come to a conclusion, if it should be added or not.
In an ideal world there would be no need for your project, because all patches make it upstream quickly. I think the discussion should be more
on
how to get closer and closer to this situation. I think it should more be found in mentoring and providing more feedback.
Well, feel free to provide concrete suggestions if you have a better idea how to solve that. ;)
Since Wine is an open source project, nobody forbids you from working on your customized Wine. Providing builds to users to try it is fine with
me,
but clearly don't mark it as the official Wine, but as you already doing by calling it 'wine-compholio'.
What does really scare me are the Fedora Wine builds. After you said that they incorporate your changes, I checked the rpm and indeed it uses 150+ custom patches from your repo. In my opinion, distro packages need to be as vanilla as possible to prevent the PlayOnLinux-like bug rejection issues. Sometimes build system change or some minor change is needed, but such an amount of patches is not justified. Myself I don't have much time to work on Wine anymore these days, but if I got bugs from Fedora users, I would reject their bugs. I hope other Wine developers would really do the same, because the packages clearly can't be trusted.
Please note that it was never our idea to get these patches into regular distribution packages. In case of Fedora the packager contacted us, and even proceeded after both Michael and I told him about the possible consequences, and that we personally don't recommend to do that. I will not cite anything here, as this was discussed in private mail contact, but I think the Fedora guys are totally aware that each bug report by Fedora users can get rejected without a comment.
Recently I also opened a bug report, since I would really prefer to have a clear statement somewhere, that people shouldn't report bugs to winehq, see: https://bugzilla.redhat.com/show_bug.cgi?id=1147271
Overall I know the intentions are good to allow users to test new code sooner and allow developers to get their stuff test sooner. I'm really skeptical about the benefit for developers due to the tainted Wine
builds.
I think overall it may actually be more negative than positive for Wine.
I don't think so. The question is just what is better: Having users reporting the same well-known issues over and over again (have to be identified as duplicates, also wastes time!), or probably a follow-up/regression issue which cannot be reproduced with vanilla Wine (bug reports can be easily closed, when error description doesn't match on developer machine). As you might know, the second problem already applies to a _huge_ amount of bugs, since users already use various (often unnecessary) winetricks recipes without knowing what they do, or report bugs when using PlayOnLinux or at least wine-multimedia (= _every_ Ubuntu user). Unless Wine reached a state, where it works out of the box with almost every app, there will always be a specific part of users with patched/modified versions - our approach is just a bit more combined and organized than some of the previous attempts, by reducing this to work-in-progress solutions. ;)
If you want a solution to find out if a version contains our patches: Just ask the users on the bug tracker to run "wine --patches".
Thanks, Roderick
Regards, Sebastian
Having "wine --version" report wine-compholio would be a welcome change, imo. Also a message to terminal a la winepulse, as Rosanne suggested.
Thanks guys for doing this! On 10/01/2014 08:27 PM, Michael Müller wrote:
since I already revealed our staging tree idea in a mail which I accidentally send to wine-devel, I think it is time to explain the whole idea. Before you start complaining, please carefully read the whole mail, and especially note that we're in no way trying to compete with vanilla Wine (which seems to be the main counter-argument I've heard so far).
I was thinking of doing this myself for a good while now but due to the lack of round tuits I had to keep postponing it. Yes, Wine needs a stage tree. Alexandre doesn't scale so shielding him from the 10th iteration of a ugly hack^W^Wexperimental patch is good. Also the current development form breaks down for big and sometimes small changes where the proper design isn't known from the start. Think DIB engine, Android, USB, D3D command stream. Those cannot be developed inside upstream Wine. There is no need to fret that this is a Wine fork. Of course it *is* a fork. Like CrossOver and every Wine packaged by a distribution. As long as it tracks and pushes stuff to upstream there is no issue with it. And it trains more people as maintainers which is good. bye michael
On 5 October 2014 23:17, Michael Stefaniuc <mstefani(a)redhat.com> wrote:
Also the current development form breaks down for big and sometimes small changes where the proper design isn't known from the start. Think DIB engine, Android, USB, D3D command stream. Those cannot be developed inside upstream Wine.
There's no reason the D3D command stream work couldn't have been done against upstream Wine, and in fact that's exactly what I did before handing it over to Stefan. (For reference, one of the first commits for that is 1ef4f075c160a826a57e8cf5613a3211005c8eb9.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-06 08:13, schrieb Henri Verbeet:
There's no reason the D3D command stream work couldn't have been done against upstream Wine, and in fact that's exactly what I did before handing it over to Stefan. (For reference, one of the first commits for that is 1ef4f075c160a826a57e8cf5613a3211005c8eb9.) I don't think so, mostly because it's next to impossible to upstream something that has a reasonable probability to need reworking later on. E.g. I went through a number of iterations of ways to handle resource updates until I found one that actually works with real-world OpenGL implementations, and I know even the current way is flawed, even though it works in practice. Yet I believe writing the current code was essential to find out what the actual driver limitations are and which requirements/bugs games have.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUMlgCAAoJEN0/YqbEcdMwjCIP/j8EzV0YGO57+KsXOu8MVWY3 T1EYCCwVCMMZjpS5rI4iVzzcQABW2HUaOm3n/suAqB+HT1ozQhFU/yv8MegyOJJz eQeUV54crdBVsdTIGH5QSqfamevRebV5JVhGZJEh0EXBRdmW3evSRBtV6KcYs0+P /h90vl6L5tMTuwlP/MceJjp9U8eJj5Qpte93itfoICeBq+AqrsUwuOYot5luoNSp D/84RYKVdO8ezalr5A+pO8QRmFU/gNCcOAEQMAzbCrBbGbZDMl74aaXlZQrtzFMy HogHT8blB4jmId1q1UqvImX3EAc7p8VUTF3JBdfAve5bR5pdswa6Yg2eV+IeaOs8 gPcgq/FYvTvW6pQyk1bNTd3By9bBgv8wCvRO7NyYW8WojIQP2rHdQX5odbPvf2gS KsdvveCGuHNg+jH/WlkB52zSHtNOjl2uCBaIAIFT8yA3wljIsBfxmNjaqY2kWbo/ 92yfaL4dWPhxsnduhWkQ3RaA2zObe7TCFvkq0AQplKoSN0WDB0G2xeS97oK0WAhV eUjsXyAvej/ohReed1PU5lw47PFmXTlt0wFoI+c6DunpffMIJIebL7ChnS1pzGhF /KscfxbaKBmH7mQMMZb2Oqk5cU+j9ghsXVbFyJdEAsmfhsZRhdTPywSplC+nzCqv j6qijIjEOfZE5w0UOaWG =JAw6 -----END PGP SIGNATURE-----
On 6 October 2014 10:51, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2014-10-06 08:13, schrieb Henri Verbeet:
There's no reason the D3D command stream work couldn't have been done against upstream Wine, and in fact that's exactly what I did before handing it over to Stefan. (For reference, one of the first commits for that is 1ef4f075c160a826a57e8cf5613a3211005c8eb9.) I don't think so, mostly because it's next to impossible to upstream something that has a reasonable probability to need reworking later on. E.g. I went through a number of iterations of ways to handle In my experience that's not true at all, unless you actually mean "is obviously going in the wrong direction" with "has a reasonable probability to need reworking later on".
resource updates until I found one that actually works with real-world OpenGL implementations, and I know even the current way is flawed, even though it works in practice. Yet I believe writing the current code was essential to find out what the actual driver limitations are and which requirements/bugs games have.
There's of course no reason you can't test your own code without a staging tree. And quite frankly, almost all the work I did on the command stream without a staging tree is upstream, and very little of yours is. There are probably legitimate arguments for having a staging tree, but the wined3d-csmt tree is more of an argument against than for. Properly maintaining a staging tree is real work, and not necessarily a lot of fun. Historically these kinds of trees haven't ended up being an overwhelming success, but who knows, perhaps this time will be different. As long as it doesn't take away too much from the already somewhat limited testing done against the main tree, I just wish everyone the best of luck. (I.e., I'm fairly skeptical this will work out, but as long as it doesn't cause the project too much trouble I see no reason to tell other people what to do with their free time.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-06 12:06, schrieb Henri Verbeet:
There's of course no reason you can't test your own code without a staging tree. And quite frankly, almost all the work I did on the command stream without a staging tree is upstream, and very little of yours is. I stopped working on upstreaming the command stream after you made a d3d10/11-like resource interface the de-facto requirement for merging location management in a (sub-) resource class (https://www.winehq.org/pipermail/wine-patches/2013-October/127312.html, and later on a series that introduced a subresource class in the wrong way). I worked on moving away some surface and volume methods as time permitted but gave up on upstreaming the CS until you're done with d3d10/d2d.
The same concern regarding resource structures would apply to 694cdcc41cc74eff8c1d96ac0e18895862b22476 and the draw_binding counterpart in my eyes. Maybe it's time to re-visit merging location management in the resource class without first eliminating surfaces and volumes entirely after I'm done with the focus loss work? (Otherwise I'll go on moving away more calls to surfaces and volumes.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUMnMNAAoJEN0/YqbEcdMwWTMQAIMtVgy94PJ5iFWLzyfasT6d TqioRjel9/yqpMcwzHVRN5zeNe1UjZndZhnF+PoHPcThHBfz5zWRbODyMlbGwSTF I5RTqis8INwx4lTZFmJzSMiRK2sxy4PislPAw/LpAAft90+J4yWyqrJu/g8+7BKS KEa8rFWsbPhcqzQDzcA0YE13yex1ez50bo8HGNTJy5eC14aYw23+PS0xvWnu26Hs 9mH+Xt8DfR5M+8fFU/p4QlBmk6G+XSyLbv8aZ6iXFPnhCjtpG9J0AA7S79hUUgV/ 63vOoh6GbkOBD2b4cEXo56HifZxlNsSSnLbKrj22fDKjMIz9jfsn1WLLP6koHz+3 wLteUFPm9zApH1gjCznnbZoTg9t0wwaWLEfCJRv73+y8lYwoq1G/MRHc8RKd4+4P RJkHvjiDSIKKkKQe0rtTjyZ826PvKdbmoubrPSAZYBrNORw6rldz+uGCaO7yLVca xdERod5WSlDR1K8rYBAhn9Y+uUuf124sj6M/gZ6nf8x0m4CKsRyZNJfmgE/xd4mp kDHKBc7BXUediTQWcrepqanYB8b8VfEYMfPFNnXoGvinlv7kb0030UFMf5qzr0yz hCXAqZ8gpnuXhJ3AolsFxnrd74JK5UTd9HJAoHOfWpc+Jaquax3KZse+6Gzbq8Ml cPYlgWUb3aMnKXpp58JH =ByGd -----END PGP SIGNATURE-----
participants (9)
-
Austin English -
Henri Verbeet -
Michael Müller -
Michael Stefaniuc -
Roderick Colenbrander -
Rosanne DiMesio -
Scott Ritchie -
Sebastian Lackner -
Stefan Dösinger