Project:Wine/Policies and Procedures

This page contains policies procedures for maintaining Wine in Gentoo. It is intended as a reference for project developers.

Policies

Supported versions

As of 01/18/2017, current project policy is to support only the current development branch and only the current stable branch. With few exceptions, all versions from this branch are to be supported. This means that all 1.8.x ebuilds and all 1.9.x ebuilds are slated for support and versions < 1.8 are no longer supported.

Release Candidates

Release Candidates are not supported, particularly for a "stable branch" because they are actually part of the development branch and adding them muddies the waters of stable vs development versions in Gentoo. If a user needs a release candidate, they can very easily set WINE_COMMIT for a live ebuild, like

root # WINE_COMMIT="wine-2.0_rc5" emerge -1a '=app-emulation/wine-9999'

Revision bumping/ebuild modification

All version-agnostic changes should be replicated to all supported versions. This means, for instance, if a patch needs to be added to support a new version of Flex, all supported versions should have their ebuilds patched with the new patch for Flex. This may include backporting patches, meaning they should be applied to all versions/ebuilds prior to the version where they were adopted upstream. Only one revision per version is to be maintained, with the exception of the most recent stable or stable candidate. For stable or stable candidate, a second revision may be maintained to either prevent modification of the existing stabilized ebuild, or to prevent modifying a soon to be stabilized ebuild (thus resetting the 30 day window, delaying stabilization)

Third party patches

With the exception of several major patchsets with upstream and downstream support/support agreements (wine-staging, d3d9, wine-gstreamer for wine-1.8.x), generally speaking, patches should not be added without being accepted upstream (and thus being backports for Gentoo). This avoids conflicts with wine-staging, minimizes live ebuild breakage, and reduces workload from failure of upstream to adopt a particular patchset (or even going with a conflicting patchset). Users with patches for Wine are encouraged to submit them upstream according to upstream's patch submission policies, and it should be noted that their patches are most likely going to be denied downstream until after the issue has been resolved upstream.

Stabilization

To ease the burden on arch teams, in accordance with amd64 and x86 team policies and with consultation with and approval from Ago, the Wine Project may self-stabilize, provided that it follows the procedures set forth below.

User contributions

Due to the complexity of Wine, its packaging, and these policies and procedures, version bumps may only be undertaken when thoroughly vetted by a project member in compliance with this page's information. This does not mean that a user cannot submit patches for ebuilds, this merely means that bumping and stabilization requires full due diligence on the part of a project member, not merely the acknowledgement of being OK by a third party.

Contribution steps:

1. Prepare a patch against wine-vanilla and wine-staging
2. Get it reviewed by Project:Wine, then push to ::gentoo, or ask us to do it if you don't have permission.

Zero-day bump requests

Zero-day bump requests will be closed as RESOLVED-INVALID.
Vanilla Wine is typically released every 2 weeks on Friday. As such, we are aware of this, and will get to it as soon as possible. Requests made < 48 hours after a Wine release will be considered zero-day bump requests.
Wine-Staging is typically released 2-4 days after vanilla Wine is released. Once again, we are kept aware of this, and will get to it as soon as possible. Requests made < 48 hours after a Wine-Staging release will be considered zero day bump requests.
TL;DR: There are lots of moving parts, and they generally occur on a schedule, that we keep track of. Ask before giving us time to act, and it'll be closed as RESOLVED-INVALID. Rule of thumb, request no earlier than Wednesday (~5 days) after a Wine release.

Procedures

Revision bumping/ebuild modification

TODO

Version bumping

1. Copy most recent ebuild in the appropriate branch to the new release. See below for more information. Example:
   cp wine-9999.ebuild wine-1.9.24.ebuild
cp wine-1.8.5.ebuild wine-1.8.6.ebuild
2. Check whether Gecko or Mono has been bumped:
   Check dlls/appwiz.cpl/addons.c for changes to #define GECKO_VERSION or #define MONO_VERSION
   Two versions may be diffed online like so: http://source.winehq.org/git/wine.git/blobdiff/TAG1..TAG2:/dlls/appwiz.cpl/addons.c
   For example: http://source.winehq.org/git/wine.git/blobdiff/wine-1.8.5..wine-1.8.6:/dlls/appwiz.cpl/addons.c
3. Check whether Wine-Staging has bumped Gecko or Mono:
   Check for modification of dlls/appwiz.cpl/addons.c, specifically #define GECKO_VERSION or #define MONO_VERSION
   Check patches for gecko or mshtml and mono or mscoree
4. Fetch sources with pkgdev manifest
5. Confirm that all major patchsets apply without conflict.
   This is typically done with TODO LINK TO SCRIPT
6. Confirm that all major patchsets compile and install without issue.
   This is typically done with TODO LINK TO SCRIPT
7. Runtest basic and/or patchset functionality.
   Examples include: TODO LIST

Stabilization

TODO