Originally posted by siavashserver
Next, if you're ready to submit:
1) Join the [email protected] mailing list (otherwise mails get stuck in a moderation queue until they get approved).
2) Use git send-email [email protected] ${git commit which is the one before the start of your patch series}
That git command will find all patches newer than the one that you specify on the command line and will send each patch as an email to the mesa-dev mailing list. It generates a diff/patch for each and quotes it in-line so that it's easy for the rest of the list to provide in-line feedback/comments. If you've got more than 2-3 patches, it would also be good to include a cover letter (Add the "--compose" param to your send-email call).
There's a good chance that your first version won't get approved immediately. Either there'll be coding style changes, or functionality changes, or something else that someone wants fixed. Don't get discouraged. When you've made the requested changes, send a v2 of the patches (and include at the bottom of each commit message a summary of what changed in each successive version).
It's probably also good to include a note in the cover letter that you don't have commit access to the upstream mesa repository. It's an indicator that someone with push access should commit your patches for you once they've been reviewed successfully.
The same workflow generally applies to piglit patches (list address is [email protected]). In general, if you're fixing a bug that doesn't have a piglit test that exposes it, it's always good to create and submit a test that exposes it. Same with enabling new features (we want to know that the new feature works properly).
Since you're working on an extension that's not supported by your radeon's binary drivers, it'll be hard to run a comparison test on catalyst. But if you work on anything that is not supported by mesa, but is supported by another driver that you have access to, it's always good to run the tests on as many drivers as you can, just to make sure that the various drivers agree on how the implementation should be done (and that you haven't coded the implementation and the tests incorrectly). Just keep in mind that the catalyst/nvidia binary drivers are occasionally wrong too.
Comment