SubmittingPatches v2

Under Construction / Barely a draft!

Murph is off to class for the day / will get back to this later

I've decided to write an updated, easier to use patch-submission guide. When it's done / look over by some others, I'll rename it / move it over the old one. I'm also open to the possibility of updating other things based on this, instead. Thanks / Suggestions are welcome! --Murph (Matt Finnicum)

Todo:

Perhaps find a wiki page with just the coding guidelines, or create one.

Documents this draws from: http://wiki.winehq.org/SubmittingPatches http://www.winehq.org/site/sending_patches http://www.winehq.org/site/docs/winedev-guide/codingpractice

Generating the patch itself

Using Git

The Wine Project uses the Git revision control system. In most cases, your best option is to follow the directions on the GitWine page to clone the wine git repository, and then use Git to generate your patches. Git has many useful features, like allowing you to create local branches, that are worth learning about if you'll be using it much.

For more detail on how to use git (This guide will mention which commands are used, but not every step required - see GitWine before running git commands you're unsure of)

Before Generating a patch, make sure your changes:

  • are 'committed' (running "git status" will show you a list. Anything in the "Changed but not updated" section is not committed)
  • are based on the newest possible code (after committing everything, use git fetch and git rebase to do so)
  • compile properly (running "make distclean && ./configure && make depend && make" would be best, time permitting)

  • don't cause any regression tests to fail ("make tests" - as many tests should pass as before your code. If more pass, update the todo_wine blocks in the tests themselves to reflect this)
  • Adhere to wine's coding guidelines
    • No C++ style comments use /* */ instead of //
    • Keep use of spaces and tabs consistent with the file you're editing. Usually, avoid tabs completely.
    • When possible, keep column width under 80 chars - again, be consistent with the rest of the file.
    • No application specific code/hacks
    • Don't generate compiler warnings

Generate a patch / patchset: This command will generate patches from all the commits between the origin branch (most recently fetched copy of the wine source) and your current branch. It will put them in the folder "out" (if you have several branches, you might want to vary where you have format-patch put the patches).

git format-patch -o out origin

After Generating the patch:

  • Open up the generated patch in a text editor, and make sure things look right.
  • When you put together your e-mail, your will probably want to cut/paste things from the top of the generated patch file.

Not Using Git

If you're set on not using Git for your patch, then you can manage without. Obtain the latest sources however you wish, and then follow the above guidelines for "before generating a patch", skipping the ones that require git commands. Then, obtain the diff in unified diff format (diff -u, from the base of the source tree).

Composing the patch e-mail

Watching the patch / Dealing with it not getting in

SubmittingPatches v2 (last edited 2008-05-03 02:41:03 by nathan.n)