Difference between revisions of "Wine-Syncs-2.0"
(Created page with "= ! THIS IS WIP ! = == Overview == For a long time wine-syncs have been done "by hand", i.e. either one of these methodds: * Merging the latest wine-commits onto our wine-sha...")
Revision as of 22:58, 17 February 2018
! THIS IS WIP !
For a long time wine-syncs have been done "by hand", i.e. either one of these methodds:
- Merging the latest wine-commits onto our wine-shared modules
- Copying the latest wine-code + applying a ros-diff.patch
- Copying the latest wine-code + manually looking for "#ifdef __REACTOS__"
This is abviously a very annoying and inefficient process.
Trying to get our patches into wine was a very tedious process and at some point we decided to go with wine-staging, which made providing patches upstream much easier. The result was that we still had our own modificatgions + modifications from wine-staging, until they were merged into the main repository.
So basically it was a huge cluster making love.
At some point the people from wine-staging got too busy with manging their stuff (which is fact nothing but a large set of patches + some scripts to apply them). So their stuff got outdated and the latest revision was based on wine-2.21, when wine was already at 3.x. At this point the attempt was made to go back to wine and keep our own changes manually. But it turned out that the process of going back to vanilla wine cause a number of regressions, e.g. oleaut32 completely losing it's 64 bit code. Now wine-staging has basically given up, and the future is unknown. So it was decided to go with a new process. Wine-Syncs 2.0!
The new process is no longer based on patch sets (either from wine-staging or our own), but instead completely utilizing the power of git. (Yes, git can handle patches, rebase them, etc. Someone should have told the guys from wine-staging, that might have made our work easier...). So we have our own wine repository now, which is a clone from wine. But we also keep both wine-staging as well as our modifications in branches. Here is the current structure:
- master - Original from wine. No changes ever go in there. The remote is wine, which is used to pull in the latest changes.
- wine-staging/* - All branches with this prefix are wine-staging applied directly on wine.
- wine-staging/<a.b>/<module> - All branches with this prefix are wine-staging version a.b.c applied on wine a.b.c.
- wine-staging/<a.b>-on-<x.y>/<module> - All branches with this prefix are wine-staging version a.b.c. rebased onto wine x.y.z.
- reactos/<module> - All branches with this prefix are the current reactos changes, not including wine-staging.
- reactos+staging/<module> - All branches with this prefix are the current reactos changes, including (on top of) wine-staging.
How to sync
After the initial (tedious) phase of setting everything up, individual module-branches will probably go away and the process of syncing shall be the following:
- Update wine
- Check out reactos.org/wine.git:master
- Pull master from the remote wine
- Push to remote origin with tags
- Update wine-staging
- Get your latest patch set from wine-staging (wherever that may be hosted)
- Reset the branch wine-staging to that revision
- Apply the wine-staging patches
- Tag the branch as wine-staging/v<a.b>
- Optional: rebase wine-staging on top of "latest" wine revision
- Rename the branch to wine-staging/<a.b>-on<x.y>
- Rebase reactos
- Check out the branch reactos