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.
Requirements
Our standards are less strict than upstream Wine, but we do still have some requirements:
- The patch must be a step in the right direction; that is, we don't allow patches that are gross hacks, or take an obviously wrong approach to solving a problem. The end goal is always to submit the patch upstream eventually, so work should progress in that direction.
- The patch must have a bug attached. We place great value on traceability, so we require all patches to have an associated WineHQ bug (exceptions may be granted under special circumstances). We also strongly encourage all discussion to take place on the relevant bug.
- Like upstream Wine, a patch must have correct attribution. If you did not write a patch, you must make this clear (ideally using the From: line in the patch itself).
- Unlike upstream Wine, we do not require sign-offs. We take sign-offs to mean the same thing as they do for upstream Wine: that you consider your code to be good enough to go into upstream Wine and to meet all of the legal and technical requirements thereof; accordingly a sign-off is not necessary for Staging patches, which do not need to meet these requirements. However, if you do provide a sign-off, be aware that your sign-off may be preserved by someone else who submits the patch upstream.
- Like upstream Wine, we do not take contributions from anyone who has disassembled or reverse-engineered Microsoft code, or seen sources (whether leaked or publicly available).
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, Zebediah Figura, or Paul Gofman) as CC, with the explicit request that the patch be considered for Staging. Please be explicit and provide details about the patch if you can, and tell us why you are submitting the patch into Staging rather than upstream Wine. 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.
We prefer patches to be formatted for submission using
git format-patch, as this is how all patches are stored in the Staging
repository itself. If you have several patches, please compress them
into a single tarball or zip instead of attaching each one individually.
However, if you have several patches which fix individual bugs (e.g. a
series of patches in different areas that are needed to allow a certain
application to work), these should ideally target separate bugs in
Bugzilla, which can be created if necessary.
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. Since we use Bugzilla as a patch tracker, further discussion on a patch will take place on the bug report, so make sure you are subscribed to it.
Packaging
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 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.
Testing
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.