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. * Which patches should be sent to Staging? Normal patches should be sent to wine-patches. If Alexandre or a reviewer decides that the patch is dangerous or not good enough, they would tell you to try to get it into Staging first. Someone of the Wine Staging team will then be assigned as reviewer, and provide additional feedback / instructions how to proceed. If the patch just needs some additional testing, we will directly add it to Wine Staging. Otherwise we will ask you to create a bug report, where the patch can be improved iteratively. If you already know that your patch is very experimental, you can skip the first step and directly create a bug report as described above. * What happens after my patch got into Staging? This depends a bit on the reason why your patch was added, but usually one or more of the following things will happen: * you continue working on the patch and send us an updated version * someone else improves the patch (list all authors, for example by signing off the modified patch) * we remove / replace your patch if it turns out to be wrong or if we find a better solution * we (or you) send the patch to wine-patches if we think it is ready Although there are quite a few people testing git versions of Wine Staging, it sometimes makes sense to wait till the patch was included for one release to ensure that it does not introduce any regressions. I hope this answers all your questions regarding the patch submission to Wine Staging :-) Regards, Michael
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.
On Fri, Oct 23, 2015 at 1:23 AM, Nikolay Sivov <bunglehead(a)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. -- -Austin
On Sat, Oct 24, 2015 at 12:02 AM, Austin English <austinenglish(a)gmail.com> wrote:
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.
I have worked with Wine Staging in the past and there are more patches to Wine Staging in my todo list, from my personal experience, tracking patch using bugzilla is quite convenient, but I also understand that it would be great to have patch review process happen in place like wine-devel. Could we configure Wine Bugzlla in a special way that all bugs with `patches` tag will automatically CC wine-devel? In that case subscribers of wine-bugs(a)winehq.org could easily filter out patches mail without being spammed of other bugs mails, at the same time we also keep the convenience of tracking work-in-progress patchset. -- Regards, Qian Hong - http://www.winehq.org
I think the point here is that a patch in Staging is unlike a patch in Development. Once accepted, it's not supposed to just sit there and silently make things better, it's supposed to continue to develop (and/or get wider testing) and eventually land in Development in some form. It seems the Staging maintainers have settled on using Bugzilla to track that. We could perhaps have a process where patches for Staging are first submitted to a mailing list, then when they're accepted into Staging a bug is created for them. That would give us consistency in the submission process, but it breaks up the discussion. And since patches are going to be picked up from wine-patches, it sounds like we'll sort of have that anyway (but with more flexibility for contributors)? I think the only question here is whether submitting through bugzilla as an intermediate step misses something important that we'd get from the mailing list. If a patch is added to Staging, improved by others, and eventually sent to wine-patches, it may end up without a sign-off from the original author. Or, if we're picking up patches from bugzilla, maybe there's a risk that the original author doesn't understand they're making a contribution to Wine? I don't have a position on whether these are real problems, just seems worth considering. I feel like a bugzilla keyword might be better than using the staging product. Often, there's going to be an existing Wine bug that will have any proposed patch attached to it, and I'm not sure it makes sense to file a new bug just to bring the patch to the attention of the Staging maintainers. Also, if the bug is in the Wine product, it can use a Wine component, which may bring it to the attention of people with an interest in that component.
On 23.10.2015 19:02, Austin English wrote:
On Fri, Oct 23, 2015 at 1:23 AM, Nikolay Sivov <bunglehead(a)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.
On 23.10.2015 08:23, Nikolay Sivov wrote:
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.
The development branch has more infrastructure for patch management than just the wine-patches and wine-devel mailing list, you also have to take into account the patch status page for example. Even the development branch of Wine, where most of the patches go upstream right on the next day, needs a way to keep track of the patch status. For our Staging tree we need that even more because the time between iterations can be much longer. Using the bugtracker for that is very convenient because, as Austin has already mentioned, all iterations and comments are located at one place. Even if the last version of the patch is about a year old, we could still keep the bug report open, if there is any value in those patches. We have been using our own bugtracker for that since over a year, and were pretty happy with this way of maintaining submissions so far. I also think that the suggested solution does not hide anything from the rest of the Wine developers. The WineHQ bugtracker is publicly available to everyone, and flexible enough to configure all kind of notifications you want to receive. I would guess most people are not really interested in Staging tree related submissions, because even in the month after WineConf, I didn't receive any offers from "new people" to help cleaning up our patches for example... but if there is, it doesn't sound like something which is impossible to solve. I have no problem with alternative suggestions, but just saying "use the mailing lists" doesn't work. Mailing lists do not replace proper patch tracking, which is what we are really talking about here. Best regards, Sebastian
participants (6)
-
Austin English -
Michael Müller -
Nikolay Sivov -
Qian Hong -
Sebastian Lackner -
Vincent Povirk