Wine-Staging Maintenance

From WineHQ Wiki
Jump to: navigation, search

While the current maintainers of Wine-Staging have no intention of disappearing without warning or training their successors, we have been bitten by that situation before. In the interest of ensuring the project can always be passed on, I'll try to document the process of maintaining it.

Organization

The layout of the Staging repository is mostly self-explanatory. The staging/ directory contains tools to maintain the patches, and the patches/ directory contains the patches themselves, as well as the `patchinstall.sh` script to install them. Each set of patches is contained within a single folder, labeled `component-Short_Description`, where the component is the most salient DLL or source directory (as with upstream Wine). Each set contains one or more patches, plus a `definition` file. This latter file uses a relatively simple format that looks like this: Fixes: [10000] The original win32 api implementation is still more popular than wine. Depends: ntdll-Some_Dependency Depends: server-Another_Dependency Disabled: true The Fixes: line gives the bug number in brackets, followed by a description of the bug (preferably copied from the bug title). Multiple bugs can be linked, though preferably one patch set should correspond to one bug. The bug number (and indeed the entire Fixes line, or in fact even the whole `definition` file) can be omitted, but we heavily discourage this, as we are still having to deal with large numbers of patches with no traceability, that cannot be tested, improved, or justified.

Each Depends: line gives the name of a patch that must be applied before this one is applied. Sometimes this dependency is given for the purpose of functionality; i.e. this patch simply won't work without its dependency also applied. More often it's given because the two patches touch closely related code, and the diffs would conflict if they were applied independently.

A Disabled: line may be added if necessary. We try to avoid this if at all possible. A disabled patch is not being maintained, is not being rebased, is not being tested, and is really useless to everyone, with the exception that it's at least visible if anyone wants to look for it. The line may be omitted if the patch is not disabled (i.e. you don't have to put false).

Rebasing

Staging is a huge set of patches (as of the time of this writing, about 900) which, if not frequently rebased, can quickly grow out of hand. We rebase daily, after Alexandre has committed the day's usual batch of patches from the mailing list. We don't rebase incrementally on top of each patch, but just on top of the whole set from the day.

The Staging repository includes a tool, staging/patchupdate.py, that automates the process of checking for conflicts. It also checks the definition files for each patch set, to see if the bugs referenced there disagree with the bug status on Bugzilla (i.e. if a Staging patch references a bug, that bug should be marked STAGED and should refer to the patch URL, and vice versa).

todo