Difference between revisions of "Sending Patches VLC"
m (0.9 -> 1.0) |
|||
| Line 13: | Line 13: | ||
* it mostly '''complies''' to the [[Code Conventions]] | * it mostly '''complies''' to the [[Code Conventions]] | ||
* Make sure that it does not add more failure to '''`make check`''' | * Make sure that it does not add more failure to '''`make check`''' | ||
| − | * Make sure that your patch is produced against the latest '''master branch''' and not 0 | + | * Make sure that your patch is produced against the latest '''master branch''' and not 1.0-bugfix. [1] |
* Make sure your patch doesn't introduce '''trailing spaces''' (''git show --colored'' show them in red) | * Make sure your patch doesn't introduce '''trailing spaces''' (''git show --colored'' show them in red) | ||
* Make sure '''your name is correctly set'''. That is, that you are using your fullname, which is correctly capitalized and so on. | * Make sure '''your name is correctly set'''. That is, that you are using your fullname, which is correctly capitalized and so on. | ||
* Read your patch one more time using '''''git show''''', and check that it looks ok | * Read your patch one more time using '''''git show''''', and check that it looks ok | ||
| − | [1] Most of the time patches are against branches version such as 0 | + | [1] Most of the time patches are against branches version such as 1.0.x series which is not a development version. If this is a bugfix it may be backported to 1.0-bugfix, but should go in master branch first. Translations are one exception to this rule. |
== Sending it to the vlc-devel == | == Sending it to the vlc-devel == | ||
Revision as of 09:53, 11 August 2009
Contents
How to produce a Patch
- Get the latest Git revision
- Make your changes and commit them
- Produce a patch according to the Git page, don't send it yet, read the following before sending.
Writing an appropriate description
- The patch email's subject should be prefixed by "[PATCH]".
- You should include a description that will be the commit log message of your patch
- A more exhaustive explanation is also welcomed along with your patch. This should be the second paragraph of your commit log.
Check List
When you send a patch make sure that:
- it mostly complies to the Code Conventions
- Make sure that it does not add more failure to `make check`
- Make sure that your patch is produced against the latest master branch and not 1.0-bugfix. [1]
- Make sure your patch doesn't introduce trailing spaces (git show --colored show them in red)
- Make sure your name is correctly set. That is, that you are using your fullname, which is correctly capitalized and so on.
- Read your patch one more time using git show, and check that it looks ok
[1] Most of the time patches are against branches version such as 1.0.x series which is not a development version. If this is a bugfix it may be backported to 1.0-bugfix, but should go in master branch first. Translations are one exception to this rule.
Sending it to the vlc-devel
Now you can send it to the vlc-devel. Please subscribe to it before sending your patch, or else it may not got through the list's spam filters. You will be able to unsubscribe later easily if needed. Don't send patch bigger than 30kB on the mailing list. If the patch is that big, it's likely that it does too much at once and should be splitted in several logical patches. If you really need a big patch, put it online and send vlc-devel@ the URL.
Getting your patch merged
- Don't hesitate to ask for review if after a week there is no replies.
- If there are comments, please answer to those and eventually correct your patch if possible.
That should ensure that your patch gets merged.
