Difference between revisions of "Sending Patches VLC"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| − | == How to produce a patch for VLC == | + | == How to produce a patch for VLC == |
| − | * Get the latest [[Git]] revision | + | |
| − | * Make your changes and commit them | + | *Get the latest [[Git]] revision. |
| − | * Produce a patch according to [[Git#Submitting_patches_to_the_vlc-devel|the Git page]], '''don't send it yet''', read the following before sending. | + | *Make your changes and commit them. |
| + | *Produce a patch according to [[Git#Submitting_patches_to_the_vlc-devel|the Git page]], '''don't send it yet''', read the following before sending. | ||
== Writing an appropriate description == | == Writing an appropriate description == | ||
*The patch email's subject '''should''' be prefixed by "'''[PATCH]'''". | *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 | + | *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 could be the '''second paragraph''' of your commit log. | *A more '''exhaustive explanation''' is also welcomed along with your patch. This could be the '''second paragraph''' of your commit log. | ||
| − | == Check List == | + | == Check List == |
| − | When you send a patch make sure that: | + | |
| − | * it mostly '''complies''' to the [[Code Conventions]] | + | When you send a patch make sure that: |
| − | * 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.1-bugfix. [1] | + | *it mostly '''complies''' to the [[Code Conventions]]. |
| − | * Make sure your patch doesn't introduce '''trailing spaces''' (''git show --colored'' show them in red) | + | *Make sure that it does not add more failure to '''`make check`'''. |
| − | * Make sure '''your name is correctly set'''. That is, that you are using your fullname, which is correctly capitalized and so on. | + | *Make sure that your patch is produced against the latest '''master branch''' and not 1.1-bugfix. [1] |
| − | * Read your patch one more time using '''''git show''''', and check that it looks ok | + | *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.1.x series which is not a development version. | + | [1] Most of the time patches are against branches version such as 1.1.x series which is not a development version. If this is a bugfix it may be backported to 1.1-bugfix, but it probably should go in master branch first. Translations are one exception to this rule. |
| − | If this is a bugfix it may be backported to 1.1-bugfix, but it probably 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 == | ||
| Line 28: | Line 30: | ||
''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. | ''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. | ||
| − | ''Try'' to avoid sending patches bigger than 100kB on the mailing list, if you can. | + | ''Try'' to avoid sending patches bigger than 100kB on the mailing list, if you can. |
| − | == Following your patch == | + | == Following your patch == |
| − | You can check if your patch was received by the list at the [http://mailman.videolan.org/pipermail/vlc-devel/ list archive] | + | You can check if your patch was received by the list at the [http://mailman.videolan.org/pipermail/vlc-devel/ list archive]. |
| − | If the patch gets approved, then there will normally be a post to the vlc-devel list to say "patch applied". There will also be a post to the [http://mailman.videolan.org/pipermail/vlc-commits/ vlc-commits] list ([http://mailman.videolan.org/listinfo/vlc-commits subscribe here]) | + | If the patch gets approved, then there will normally be a post to the vlc-devel list to say "patch applied". There will also be a post to the [http://mailman.videolan.org/pipermail/vlc-commits/ vlc-commits] list ([http://mailman.videolan.org/listinfo/vlc-commits subscribe here]). |
== Getting your patch merged == | == Getting your patch merged == | ||
| − | *''Don't hesitate'' to '''re-ask '''for review if after a week there are no replies or comments | + | *''Don't hesitate'' to '''re-ask '''for review if after a week there are no replies or comments. |
*If there are comments, '''please answer''' to those and eventually correct your patch if possible. | *If there are comments, '''please answer''' to those and eventually correct your patch if possible. | ||
That should ensure that your patch gets merged. | That should ensure that your patch gets merged. | ||
Revision as of 10:29, 3 December 2010
Contents
How to produce a patch for VLC
- 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 could 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.1-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.1.x series which is not a development version. If this is a bugfix it may be backported to 1.1-bugfix, but it probably 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.
Try to avoid sending patches bigger than 100kB on the mailing list, if you can.
Following your patch
You can check if your patch was received by the list at the list archive.
If the patch gets approved, then there will normally be a post to the vlc-devel list to say "patch applied". There will also be a post to the vlc-commits list (subscribe here).
Getting your patch merged
- Don't hesitate to re-ask for review if after a week there are no replies or comments.
- If there are comments, please answer to those and eventually correct your patch if possible.
That should ensure that your patch gets merged.
