Wine-Staging Contributing

From WineHQ Wiki
Revision as of 12:37, 7 November 2018 by Zf (talk | contribs) (updates, somewhat in accordance with policies and project goals as presented at WineConf 2018)
Jump to: navigation, search

Contributing to Wine

The best way to make Staging better is to make upstream Wine better. This helps both projects, as Staging draws directly and regularly from upstream Wine. Many patches in the past which have been written for Staging have been perfectly acceptable for upstream Wine, so for any simple patch, going straight upstream is almost always better.

For new developers

We try to make the process of contributing to Wine as friendly and helpful as possible, but nevertheless it can be difficult to get patches in, especially for new developers who don't have a familiarity with the code base. One of the purposes of Staging is to provide a less demanding environment for new developers, so that patches which aren't quite up to upstream's high quality standards at first can be accepted into Staging, improved by the author with the help of the Staging maintainers, and then submitted upstream. On the other hand, some simple patches may already be quite acceptable for upstream, so don't be surprised if a patch is suggested for upstreaming right away by a Staging maintainer or someone else.

For experienced developers

Another purpose of Staging, as is suggested by its name, is to provide a temporary place for large or risky patchsets to gain some testing, so as to more completely test them for bugs and account for regressions that the changes might expose. We encourage all developers to take advantage of this facility, both to improve their code and to avoid the situation where helpful patches are long to see the light of day.

How to submit patches

As of 2018, Staging has a strict policy that all new patches submitted for Staging must have an associated bug report. This is to combat the problem where patches written cannot be verified, justified, or tested for regressions. To facilitate this, Staging uses the Wine bug tracker as, in some sense, a patch tracker. If you want a patch to be included in Staging, attach it to the bug, and then add one of the Staging maintainers (Alistair Leslie-Hughes or Zebediah Figura) as CC, with the explicit request that the patch be considered for Staging. Don't just CC one of us and expect us to know what you want; make sure you state clearly that the patch is meant for Staging. If you are writing a patch for a bug that has not yet been filed, it's perfectly fine to file a new bug. After a Staging maintainer has considered the patch, if it is deemed acceptable for Staging, we will add the patch to the Staging repository and mark the bug as STAGED. We may additionally scout existing bugs or the wine-devel mailing list for patches, but if you want to make sure we see a patch to be added into Staging, make sure you CC us and request so on the relevant bug.


We already support a large number of distributions and provide new builds every two weeks, but we can not support every single distribution. If you are using an unsupported one and you know how to create packages, feel free to do so by following the instructions in our Wine-Staging Packaging guidelines. We may also add a description on how to use your packages in our Installation instructions, if you tell us about them. Just open a bug report or contact us on IRC.


The idea behind Wine Staging is to add experimental functions and bug fixes. In order to make sure that we do not introduce any new bugs or failed to fix existing ones, we need people to test Wine Staging. We try to test as much stuff as possible on our own, but some bugs occur in proprietary software which we do not own. You should therefore try as much software as possible with Wine Staging.