[10/11] ddraw/tests: Add assorted D3D3 DrawPrimitive/visual tests.

Stefan Dösinger stefandoesinger at gmx.at
Tue Nov 8 07:23:24 CST 2011


On Tuesday 08 November 2011 12:08:21 Octavian Voicu wrote:
> It gets a bit harder when you have more than a couple of tests,
> because you have to follow the sequence of flashes, but the message
> from the failures should be descriptive enough.
I do that with things like if(i == 5) Sleep(999999). If you want to see 
something you'll have to add a sleep anyway.

> >> of d3d, d3d2, d3d3, d3d7, where to have most of the things we store
> >> globally or in local vars now, and make the create/release functions
> >> work with that.
> > 
> > Yes, I was about to write something like that as a response to the
> > cleanup patches.
> 
> Is it OK to leave them like this for now? That kind of refactoring is
> going to make this patch series endless.
I think its better to have the cleanup done before adding the d3d2/3 tests and 
infrastructure. You don't have to send all of the patches at once. I usually 
don't send more than 5 patches a day. This makes it more likely all mails make 
it to wine-patches and keeps discussions of the patches focused.

http://wiki.winehq.org/SubmittingPatches has the general patch submission 
guidelines. The "Small, clear and atomic changes" part is the trickiest aspect 
of this. All patches have to compile and pass the tests, otherwise Alexandre 
doesn't commit them. Single patches should be as small as possible, but make 
sense on their own. If you split up patches, and patch 1 prepares things for 
patch 2 and isn't needed otherwise, send them in the same patch series.

In your patches you have a few separate things:
* Patch 1 makes sense on its own
* Patches 2 and 3 clean up variables. Introduction of a structure would fit 
into those
* Patches 4, 5 and 6 fix issues on vmware
* 7, 8 add d3d2 tests
* 9, 10 add d3d3 tests
* 11 adds a d3d7 test

The separation into small patches looks good. You can send more than one of 
those patch blocks at once, but you don't have to.

Don't be afraid to have a bigger set of unsent patches in your tree, git makes 
it fairly easy to work with them. For editing patches, git rebase --
interactive is very helpful. Branches can be very useful for bigger features 
or fixes you're working on. There are also other tools like stgit that are 
worth a look.

For example, I currently have 7 unsent patches in my tree that are ready to 
go. I have 3 branches with features that I've put on ice until after Wine 1.4 
and 4 tests and bugfixes that need some more work before I'll send them(They 
currently live as test patches on my git tree on the Windows partition). I 
also have a branch with hacks for personal use that aren't of any use for 
others and will never make it into Wine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20111108/79a1c968/attachment.pgp>


More information about the wine-devel mailing list