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