Wine staging patches submission

[Alistair Leslie-Hughes]

Please clarify some things then since you've voluteered to become new
> wine-staging maintainer:
> 1. what's your vision as a maintainer for the future of wine-staging
> besides an obvious attempt to perform a "total clearance" of existing patches?
A "Total clearance" of wine-staging patches is impossible, however
evaluating which patch actually fix a bug and can be moved on is.

I see wine-staging taking on patches which might be a quick fix to
a user issue, e.g. a return S_OK, whereas upstream will only accept
a complete implement. 
Also taking on a patchset, example d3d11-Deferred_Context (was has
been in staging before my time), which in it current form works but
wont be accepted upstream as is.

Some developers have had bad experiences trying to get patches accepted
into wine and I get that.  wine-staging isn't as strict to what is
acceptable
or not. Having the ability to get a patch tested with a large user base,
so feedback
can be received is what some developers need. Especially on patches
which might
cause regressions, MFStartup patch for example. Even your windowscodecs
patches are
an example of this process.

Wine-staging is also here to helping developers getting patches accepted
into wine,
either on there own back or by someone else.

Some patches, like nvcuda, might never move out of staging, however
this patchset generally doesn't cause an issue for a rebase.


> 2. what kind of development is going on or is planned in the staging tree
> after Sebastian's and Michael's departure?
Short term, we will remove more of the burden of 900 patches that
wine-staging contains. Some patchset cause a large amount of time to be
consumed when anything in that area changes.  Trying to minimum the
rebase time would allow use to focus new and exciting patches.

Long term would be to have a flow of patches in and out of staging from
users and ourselves.

> 3. what's the role of wine-staging.com in the project?
The website, as we have just had it transferred to us, this is still being
discussed. 

> It's sad, but you clearly don't understand the things I tried to explain
> to you so many times already.
>
I understand but see things differently.  How about seeing it from my side,
Anytime windowscodecs, for example, is changed, there is large chance I
have to
rebase 1 or more patches I shouldn't have to.  Taking time away from
developing
other patches.
You could then send me the update patches but in the mean time I have
to disable 4 patchset while I wait.

Alistair.