This article provides an overview for submitting patches against the V4L-DVB source code (either for new or existing kernel driver modules and/or documentation), as well as for the [[LinuxTV dvb-apps|dvb-apps]] source. For general references in regards as to how to develop support for a particular device or in writing a new device driver, see [[Development: How to add support for a device|here]].

+

This article provides an overview for submitting patches against the V4L-DVB source code (for either new or existing kernel driver modules and/or documentation), and as well as for the [[LinuxTV dvb-apps|dvb-apps]] source. For general references in regards as to how to develop support for a particular device or in writing a new device driver, see [[Development: How to add support for a device|here]].

:* Send the patch inline, not as an attachment (unless asked to do so otherwise) ... patches presented in the form of inline text in the body of an email are easier to deal with from the perspective of a peer review process (for more information, see the <code>/usr/src/linux/Documentation/email-clients.txt</code> file; a current copy of which can also be found online [http://lxr.linux.no/linux+v2.6.28.5/Documentation/email-clients.txt here]).

:* Send the patch inline, not as an attachment (unless asked to do so otherwise) ... patches presented in the form of inline text in the body of an email are easier to deal with from the perspective of a peer review process (for more information, see the <code>/usr/src/linux/Documentation/email-clients.txt</code> file; a current copy of which can also be found online [http://lxr.linux.no/linux+v2.6.28.5/Documentation/email-clients.txt here]).

+

:* '''Note''': various web mail interfaces seem to be problematic for patch submissionn, in that:

+

:** they may break the patch (e.g. line wrapping it) or

+

:** in the case where you have sent the patch as an attachment, the emailer may use the wrong mime encoding type ... (web mailers often wrongly use "application/octet-stream" for diffs, whereas the proper type is "text/x-patch" ... Note: the patchwork tool (discussed below) is robust in that it supports both mime types "text/x-patch" and "text/plain", but if the emailer has sent it with a different type, the attachment will be disregarded/discarded.

Hint: There is also a [[Development: Linux Kernel patch submittal checklist|checklist for patch submission]]

Hint: There is also a [[Development: Linux Kernel patch submittal checklist|checklist for patch submission]]

== After you've Submitted: What happens Next? ==

== After you've Submitted: What happens Next? ==

−

In the past, it was, unfortunately, not uncommon for patches to become overlooked or lost on the V4L-DVB mailing lists. However, with the new Linux-media mailing list, V4L-DVB is now using the [http://patchwork.kernel.org/project/linux-media/list/ Patchwork tool] for aggregating patches sent into the list (you can read more about it [http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab here]). So, provided you have correctly submitted your patch, the steps towards having your code adopted will have been put into motion. You can, of course, check to see the status of your submission from the [http://patchwork.kernel.org/project/linux-media/list/ Patchwork webpage].

+

In conjunction with the move to the new Linux-media mailing list, V4L-DVB is now using the [http://patchwork.kernel.org/project/linux-media/list/ Patchwork tool] for aggregating patches sent into the list (you can read more about it [http://www.linuxtv.org/news.php?entry=2009-01-06.mchehab here]). In the past, it was, unfortunately, not uncommon for patches to be overlooked and become lost on the V4L-DVB mailing lists; thus making the adoption of the patchwork tool a very welcome addition. So, provided you have correctly submitted your patch (as discussed above), the steps towards having your code adopted will have automatically been put into motion. You can, of course, check to see the status of your submission from the [http://patchwork.kernel.org/project/linux-media/list/ Patchwork webpage]. If patchwork has not picked up your patch, it stands to reason that your submission was incorrect for some reason; please review the information contained in the above section and try again.

The first thing you should expect next is that a [[Development: Code Review|code review]] will be performed, and often this is by various parties. This may lead to a series of requests for you to fix any observed problems and require you to then resubmit your work, by repeating the steps outlined above, until everyone is happy with the submission. In other words: wash, rinse, repeat ;)

The first thing you should expect next is that a [[Development: Code Review|code review]] will be performed, and often this is by various parties. This may lead to a series of requests for you to fix any observed problems and require you to then resubmit your work, by repeating the steps outlined above, until everyone is happy with the submission. In other words: wash, rinse, repeat ;)

−

Then, when your patch is accepted, it will initially be applied to the main V4L-DVB mercurial tree. Once tested and integrated, such patches are later merged into a git tree by the V4L-DVB maintainer and periodically pulled by Linus.

+

Then, when your patch is accepted, it will initially be applied to the main V4L-DVB mercurial tree. Once tested and integrated, such patches are later merged into a git tree by the V4L-DVB maintainer and, upon request, periodically pulled by Linus into one of his git trees for an intermediate step towards inclusion into the Linux kernel.

[[Category:Development]]

[[Category:Development]]

Revision as of 23:17, 12 April 2009

This article provides an overview for submitting patches against the V4L-DVB source code (for either new or existing kernel driver modules and/or documentation), and as well as for the dvb-apps source. For general references in regards as to how to develop support for a particular device or in writing a new device driver, see here.

Send the patch inline, not as an attachment (unless asked to do so otherwise) ... patches presented in the form of inline text in the body of an email are easier to deal with from the perspective of a peer review process (for more information, see the /usr/src/linux/Documentation/email-clients.txt file; a current copy of which can also be found online here).

Note: various web mail interfaces seem to be problematic for patch submissionn, in that:

they may break the patch (e.g. line wrapping it) or

in the case where you have sent the patch as an attachment, the emailer may use the wrong mime encoding type ... (web mailers often wrongly use "application/octet-stream" for diffs, whereas the proper type is "text/x-patch" ... Note: the patchwork tool (discussed below) is robust in that it supports both mime types "text/x-patch" and "text/plain", but if the emailer has sent it with a different type, the attachment will be disregarded/discarded.

After you've Submitted: What happens Next?

In conjunction with the move to the new Linux-media mailing list, V4L-DVB is now using the Patchwork tool for aggregating patches sent into the list (you can read more about it here). In the past, it was, unfortunately, not uncommon for patches to be overlooked and become lost on the V4L-DVB mailing lists; thus making the adoption of the patchwork tool a very welcome addition. So, provided you have correctly submitted your patch (as discussed above), the steps towards having your code adopted will have automatically been put into motion. You can, of course, check to see the status of your submission from the Patchwork webpage. If patchwork has not picked up your patch, it stands to reason that your submission was incorrect for some reason; please review the information contained in the above section and try again.

The first thing you should expect next is that a code review will be performed, and often this is by various parties. This may lead to a series of requests for you to fix any observed problems and require you to then resubmit your work, by repeating the steps outlined above, until everyone is happy with the submission. In other words: wash, rinse, repeat ;)

Then, when your patch is accepted, it will initially be applied to the main V4L-DVB mercurial tree. Once tested and integrated, such patches are later merged into a git tree by the V4L-DVB maintainer and, upon request, periodically pulled by Linus into one of his git trees for an intermediate step towards inclusion into the Linux kernel.