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@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