Wine staging tree

Wed Oct 1 23:59:07 CDT 2014

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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20141001/00f55de3/attachment-0001.html>