Sending Patches VLC: Difference between revisions

From VideoLAN Wiki
Jump to navigation Jump to search
← Older edit
No edit summary
No edit summary
 
(34 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== How to produce a Patch ==
== How to produce a patch for VLC  ==
* Get the latest [[Git]] revision
* 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 ==
*Get a modern [[Git]] version, 1.7 or higher.
* The patch email's subject should be prefixed by "[PATCH]".
*Make your changes and commit them on a branch.
* You should include a description that will be the commit log message of your patch
*Check your commit.
* A more '''exhaustive explanation''' is also welcomed along with your patch. This should be the '''second paragraph''' of your commit log.


== Check List ==
== Writing an appropriate description  ==
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.
*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.


== Sending it to the vlc-devel ==
== Check List  ==
Now you can send it to the [http://mailman.videolan.org/listinfo/vlc-devel 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.


== Following your patch ==
When you send a patch make sure that:


You can check if your patch was received by the list at the [http://mailman.videolan.org/pipermail/vlc-devel/ list archive]
* The code mostly '''complies''' with the [[Code Conventions]].
* The patch applies to the latest '''master branch'''.
** Do not submit patches against a bugfix branch, except to backport fixes already found on the master branch.
** Do not submit patches against releases. That would be completely useless.
** As a special exception, language translations go to the last bugfix branch directly.
* Proper copyright license exists, and is stated where appropraite.
* The changes do not break the build.
** Testing all combinations is impossible. But you should at least test one.
* The tests suite still '''passes''' (i.e. '''`make check`''' runs without errors).
* The compiler does not mention new compilation '''warnings'''.
** In some rare cases, warnings are unavoidable or counter-productive to fix. If so, explain it in the patch description.
* If the patch adds, removes or moves one or more files, make sure the distribution still works, i.e. '''`make distcheck'''` runs succesfully to the end.
* No '''trailing spaces''' are introduced (''git show --color'' show them in red).
* Indentation is correct, no '''tabs''' are introduced.
* No unrelated changes are included in the patch.
** Especially changes to <code>.po</code> or <code>.pot</code> files do not belong within source code patches.
** As a necessary exception, tabs are allowed within Makefiles.
* '''Your name is correctly set'''. That is, that you are using your fullname, which is correctly capitalized and so on.
** For example, if you are '''John Smith''' with an e-mail of '''johnsmith@acme.example''', you should set your "Git name" to '''John Smith <johnsmith@acme.example>''' - real full name - not "jsmith", "John S", "J. Smith", "johnnykool1234", "J.S." or any other permutation.
* The patch description makes sense.
* Read your patch one more time using '''''git show''''', and check that it looks OK.


if the patch is 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])
== Sending it to gitlab ==


== Getting your patch merged ==
'''Now''' you can send a merge request against vlc.git on [https://code.videolan.org/vlc gitlab].
* 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.
== Following your patch  ==
That should ensure that your patch gets merged.
 
You will receive feedback on your merge request by core members of the VideoLAN team within a few days. It will move to the Accepted stage automatically. Rebasing your merge request will delay merging your work and consumes CI resources for nothing. We will do it for you once your work is accepted.
 
== 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.
* Do not personally ping individuals of the VideoLAN community
 
[[Category:Coding]]
[[Category:Security]]

Latest revision as of 13:53, 8 March 2026

How to produce a patch for VLC

  • Get a modern Git version, 1.7 or higher.
  • Make your changes and commit them on a branch.
  • Check your commit.

Writing an appropriate description

  • 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:

  • The code mostly complies with the Code Conventions.
  • The patch applies to the latest master branch.
    • Do not submit patches against a bugfix branch, except to backport fixes already found on the master branch.
    • Do not submit patches against releases. That would be completely useless.
    • As a special exception, language translations go to the last bugfix branch directly.
  • Proper copyright license exists, and is stated where appropraite.
  • The changes do not break the build.
    • Testing all combinations is impossible. But you should at least test one.
  • The tests suite still passes (i.e. `make check` runs without errors).
  • The compiler does not mention new compilation warnings.
    • In some rare cases, warnings are unavoidable or counter-productive to fix. If so, explain it in the patch description.
  • If the patch adds, removes or moves one or more files, make sure the distribution still works, i.e. `make distcheck` runs succesfully to the end.
  • No trailing spaces are introduced (git show --color show them in red).
  • Indentation is correct, no tabs are introduced.
  • No unrelated changes are included in the patch.
    • Especially changes to .po or .pot files do not belong within source code patches.
    • As a necessary exception, tabs are allowed within Makefiles.
  • Your name is correctly set. That is, that you are using your fullname, which is correctly capitalized and so on.
    • For example, if you are John Smith with an e-mail of johnsmith@acme.example, you should set your "Git name" to John Smith <johnsmith@acme.example> - real full name - not "jsmith", "John S", "J. Smith", "johnnykool1234", "J.S." or any other permutation.
  • The patch description makes sense.
  • Read your patch one more time using git show, and check that it looks OK.

Sending it to gitlab

Now you can send a merge request against vlc.git on gitlab.

Following your patch

You will receive feedback on your merge request by core members of the VideoLAN team within a few days. It will move to the Accepted stage automatically. Rebasing your merge request will delay merging your work and consumes CI resources for nothing. We will do it for you once your work is accepted.

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.
  • Do not personally ping individuals of the VideoLAN community
Retrieved from "https://wiki.videolan.org/index.php?title=Sending_Patches_VLC&oldid=66762"