Please clarify some things then since you've voluteered to become new
wine-staging maintainer:
- 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.
- 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.
- 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.