Wine Staging patch submission

Nikolay Sivov bunglehead at gmail.com
Fri Oct 23 11:49:39 CDT 2015


On 23.10.2015 19:02, Austin English wrote:
> On Fri, Oct 23, 2015 at 1:23 AM, Nikolay Sivov <bunglehead at gmail.com> wrote:
>> 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.
>
> Arguably, if it was already working, there wouldn't have been a need
> for wine-staging :).  I can certainly see the advantage to using
> bugzilla, namely that all discussion is in one place, no matter how
> many months go by, or iterations/threads there are to keep track of.
>

Then why are you not suggesting to move wine-patches to bugzilla too? My 
point is that every new submission should go to a single place, where 
everyone can see it (currently this is a mailing list, and it's been 
using for that very purpose for years). Once submitted it could then be 
decided how experimental or questionable a solution or proposal is, 
again at the same place, with everyone seeing it. As a result patch 
could be picked up (or not) and go one of two ways. If a submission is 
about improving existing patch it can use some marker in subject that 
clearly makes it apparent.



More information about the wine-devel mailing list