Wine Staging patch submission

[Nikolay Sivov]

On 23.10.2015 3:15, Michael Müller wrote:
> Dear Wine developers,
>
> a lot of changes regarding the integration of Wine Staging have already
> been realized, but there are also some tasks left. In this email I would
> like to talk about the ways on how to submit patches that should be
> integrated into the staging tree. So far most patch submissions were
> done through our Wine Staging bug tracker, but now we would like to move
> the patch submission to WineHQ.
>
> We had the choice between using a mailing list or using the upstream bug
> tracker. For the usual development progress a mailing list is perfectly
> fine, however patches submitted to Wine Staging are usually either
> complex, or need more work. Often multiple revisions are required, and
> we think that its much easier to keep track of the progress of a
> patchset, when all information is collected in one place. Also, it is
> much easier to use the existing bug tracker than writing tools for a
> separate staging patch overview page. ;-)
>
> * How does it work?
> We want to add a new component "patches" into the Staging product in the
> WineHQ bug tracker. If you want so submit a patch, you can then create a
> new bug report and add your patch as attachment. In case of a patch
> series, you can either put them into a tar archive, or add several
> attachments. You can sign-off your patch if you want to indicate that it
> would be ready for integration into the development branch, and just
> needs some more testing. Other developers are of course invited to give
> feedback on those patches, too. If the patch gets accepted, the status
> changes to FIXED. If the patch fixes a bug and there is no open bug
> report for this problem yet, we might also change the status to STAGED
> and move it to the appropriate upstream category.

I don't like that. We have bugzilla for tracking bug reports and mailing 
lists for discussions and patch submissions. This already works. Just 
use wine-patches or wine-devel (if patch is not ready for some reason), 
then you can pick from a list directly in a usual way. I don't see why 
you need separate patch page or additional tools. If it's not a feature 
specific to your repo why not submit it to wine directly and introduce 
this delay from having it staging for no reason for indefinite period of 
time? And whether it's ready for Wine should be a maintainer or 
collective decision (as it is now), with usual discussion on a list. If 
it needs more work say it on a list that everybody interested are 
already reading, multiple iterations are not a problem either, we have 
that all the time.

Basically I'd like it to always go through wine-patches. If it's decided 
it's not suitable for Wine for some reason (that is not patch 
correctness), you can decide if you want to keep it in your repo, 
leaving a note about that and not doing it silently. Having a way to 
bypass that is not an integration there was so much talk about.