Wine Traffic

Project Management

This topic came up on IRC so I was quite happy when Mike Hearn mentioned it on the wine-devel list as well. There has been a bit of discussion about moving from CVS to another revision control program. CVS has definitely served it's use over the years, but moving to something else may provide enough benefits to offset the change. Mike briefly summarized what he was considering:

Perhaps Wine should start considering a kernel-like approach with some developers having their own trees where some experimental patches are tried out first then percolate up to Alexandres tree?

Another thing I'd really like to see is a move to GNU arch version control - it makes distributed development and branching a *lot* easier. I talked to Alexandre a bit about this at WineConf, and he mentioned on IRC that when arch is supported by emacs he'd think about it. Well, I now see on arch-user that there is such support, and the arch tools are maturing rapidly (see zoomarch etc).

It might be worth doing an experiment on using arch for Wine development.

Maybe if I get some time this holiday I'll try reviving my program to parse CVS commit messages back into filesystem operations and begin keeping an arch archive in sync with CVS so people can try it out. The last time I tried it I found turning commit messages into FS ops reliably was a pain in the ass, but I'm better at shell scripting these days.

I already parse commit messages in realtime for CIA (our irc commits bot) so I could easily extend this and put the results on navi.

What do people think?

The emacs tool that Alexandre prefers is pcl-cvs. It's a front-end to CVS that allows many things to be performed as a single keystroke. Dimi cautioned against switching to a system people are less familiar with:

arch sure sounds interesting (except for the file naming conventions :)), but before we can consider switching we *must* have infrastructure available that's comparable to the CVS one. And here I mean:

cvsweb: for web browsing
cvsup: for fast synch
patch: for the winehq-cvs messages

Given that repositories are just files on FTP servers, maybe cvsup is not needed, but the patch facility we have is a must.

When all that is in place, we may consider looking into it, to see if the switch is worth the pain. Please remember that virtually everybody knows CVS, whereas almost no one knows arch, so for new (and existing developers) it's a big pain to switch. So we must have some pretty important reasons to go down this path, and "arch is a cool concept" does not qualify :)

This led Mike to put together a really nice list of things that arch could for Wine and how development could be improved. Some of the tools Dimi wanted replacements for already exist:

ArchZoom: http://migo.sixbit.org/software/archzoom/
ViewArch: http://arch.bluegate.org/cgi-bin/viewarch.cgi

(and concerning cvsup...) Arch already has this built in, effectively. Arch works in a fundamentally different way to CVS - it's based on applying changesets in order rather than keeping track of HEAD and working backwards.

ie running tla get wine or whatever actually downloads the first checkin then all the patches and applies them in turn. Obviously that's too slow for most projects so you can stow cached revisions (ie tree snapshots) along the way so it only downloads the last revision then works from there. That only occurs on initial checkout of course.

Arch works with changesets natively, so you can run the relevant command with the patch ID to get this sort of output at any time.

While everyone knows CVS the subset of commands we all use is tiny, mostly because only Alexandre commits. In fact I'd guess 99% of CVS usage on wine is:

cvs update
cvs diff
cvs log/status

The equivalents in arch are:

tla update OR tla replay (difference explained below)
tla file-diffs

There is no equivalent for file-based log/status AFAIK as arch doesn't track files individually like CVS does. The upside is that arch understands things like file renames/moves/symlinks.

OK, so why should we use arch?

Wine is a project that operates similar to the Linux kernel. There is a benign dictator, who controls CVS. We all grab CVS, hack in our own branches, separate the changes out into a patch and email it to wine-patches. Normally, if we got it right, Alexandre will check it in forming a logical changeset, and we then all run cvs update which downloads everyones changes.

This works OK but has a number of disadvantages:

No branches.: Some Wine work would be best done in parallel to the main tree. For instance, the filesystem work, the WM rewrite etc. Wines current modus operandi makes this very hard, as effectively CVS HEAD must be at least dogfoodable at all times. This also makes it hard to do R&D projects like the shared memory wineserver while keeping the results of that R&D usable.
Hard to work on locally: Not every patch we write gets checked in, this is the reality of life working on Wine. Sometimes because those patches are incomplete or wrong, sometimes because they get forgotten or missed, sometimes because Alexandre doesn't agree that the code belongs in the main Wine tree (things like the system tray patch, delayed debug tracing patch etc spring to mind).
Over time, a particular checkout of wine will accumulate debugging cruft, random unchecked in patches and so on. I already have one tree I've practically abandoned for new development because the differential got so large (11,000+ lines). It gets hard to separate out individual changes into atomic patches, especially when patches depend on each other.
Yes you could say I should never have allowed the diff to get so large, and believe me I wish it hadn't happened, but in practice people still use and apply patches like systray/debug tracing and expect me (!) to maintain them, so I need to keep them around in some form. There are also patches in there that bounced pending extra work that I never got around to and so on.
Nowadays I simply use separate checkouts of CVS to try and manage it all.
CVS is not changeset oriented.: It's really hard to easily do regression checks because the closest CVS has to this is date based rewinds. We try and slap changesets on top using patch.py, which works well, but CVS is not naturally inclined towards it. Arch lets you say "rewind to this changeset" and it'll just do it. Binary searches become a lot simpler.
Hard to get into The Zone: Sometimes, some people or teams of people will have a mad coding session and produce a ton of patches. The Direct3D work by Jason, Raphael and Christian last year is one good example. My WineCfg work was another. Unfortunately our current model makes this a total pain in the ass because the patches are against CVS not your previous work. I ended up writing some scripts to help with this, by having two trees which I applied patches to in sequence then generated a diff against. It was annoying. This is especially true if AJ bottlenecks - for instance during some of the D3D work he was on holiday.

Why does arch work better?

Arch is far from perfect, in particular it's rather quirky and has a ridiculously complex command line interface. However, it has one feature that is make or break : distributed branching/merging.

In arch you can have a tree in an archive somewhere up on the net, and others can make a branch of it in their own archive and start checking in changes. They can remerge periodically and arch will just deal with problems like multiple remerges (in both directions). The owner of the original tree can merge the branch into their own when the time is right, or cherrypick changesets and just apply them.

In other words, I could branch WineHQ, and make some changes, then you Dimi could branch *my* tree and make some changes yourself and so on.

So how might Wine development look in a post-arch world?

Here's one vision. See what you think.

Alexandre of course remains the ultimate maintainer and dictator of Wine. His tree is the canonical one which we all work from, and he does releases of his tree a la Linus.

However, let's say I engage on a particular project (make WinFoo work). Maybe I'm doing it for a customer, maybe I just want to make people in #winehq happy. I can grab WineHQ, branch it, and start committing. Along the way, I can submit each changeset back to wine-patches with a very simple script: arch will generate a whole-tree changeset with one command. When I next commit of course the diff will be reset to zero so I don't end up with bits of other patches interfering.

Alternatively, if there are a lot of patches which depend on each other, Alexandre can pull the tree directly and use archs built in merging operations to synchronise the two. I can keep on working while this is going on by the way - AJ can merge with my tree as many times as he likes, and vice-versa.

Let's say only 90% of the patches I write to make this app work get checked into WineHQ. Users who only care about this app are still happy as they can just "tla get mike_at_navi.cx--wine--winfoo" and grab a version of Wine that works for their app. The community is happy because the bulk of the patches got back to the main tree anyway.

Let's say Jason, Raphael and Christian have another D3d codefest. The best way to work on this is for one of them to branch WineHQ and start work. The others branch this subtree *again* and begin work on their own trees. The temporary D3D "maintainer" merges with the other guys work, and so nobody bottlenecks on AJ or has to stop work for a few days while the patch queue clears so they can get clean diffs easily.

The end result of that work can be then trivially merged back into WineHQ. Alexandre can review the entire patch at once to get the zeitgeist of it, while still seeing the progression of the code if he wishes. Meanwhile the huge code churn doesn't impact others working on other parts of the codebase.

It'd also make it practical for Wine to split into subprojects for really huge pieces of work. For instance, currently MikeM is hacking on MSI alone. If he had the ability to setup a separate project for it, and invite others to begin work with him, it might be easier to get people involved. Once the work has matured the project can be terminated and we go back to the central peer-reviewed model.

So, what do people think? There are tools to sync CVS and arch, I can set one up over the holidays (starting for me on saturday) so we can get a flavour of it, if there is interest.

Greg Turner uses it for other work and likes it:

I'm using it at my new job and it's pretty dope imho. There are a few downsides, some already have been mentioned (those--horrible--names, for example). Others I have noticed:

Too many VC files & VC Files mixed in too liberally with your real source ("inventory" helps ameliorate this, but still...)
Not the best win32 support AFAIK
working in /x/y/z amazingly requires write permission at /x/y! stupid.
horrible, confusing error messages
no fancy integration with your favorite GUI yet

Despite the above and a few other nits, I really like it. Even those--damn--names start to get comfortable once your ring finger builds up the requisite strength & dexterity :)

Erik de Castro Lopo also had good things to say about it.