Push patches upstream: Difference between revisions
No edit summary |
|||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
= | = Sourcing Patches = | ||
When you encounter problems with software, we're often not alone. For this reason its worth looking at other projects and seeing if they already have solved the problem (as well as checking if there is already a fix upstream). Good sources for patches are: | |||
* [http://patch-tracker.debian.org/ Debian] | |||
* [http://patches.ubuntu.com/ Ubuntu] | |||
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo] | |||
* [http://cvs.fedoraproject.org/viewvc/rpms/ Fedora] | |||
= Patch Guidelines = | |||
Experience shows that whilst its clear in your mind why a patch is being added at the time you add a patch, if you revisit it a year later you probably won't remember all the details. For this reason, we ask that patches clearly state some basic information. The full details are available at [[Commit_Patch_Message_Guidelines]]. | |||
= Sending Patches Upstream = | |||
OE has many patches which for many reasons would be best submitted to the upstream projects rather than being maintained in OE itself. By doing this the wider community can benefit from the changes, recipe upgrading becomes easier and it also in many cases educates the upstream software projects about how their software gets used and for example, the challenges of a cross compile environment. | |||
= Push'em-weekends = | == Push'em-weekends == | ||
These are sprints in the spirit of our [[bug days|bug-squashing weekends]] when we try to | These are sprints in the spirit of our [[bug days|bug-squashing weekends]] when we try to | ||
| Line 31: | Line 27: | ||
list of patches still in need of being documented in line with above policy. | list of patches still in need of being documented in line with above policy. | ||
find | find recipes/ \( -name '*.patch' -or -name '*.diff' \) -print0 | xargs -0 egrep -L \^upstream\: | ||
You can push those patches upstream even if you are only a normal user of | You can push those patches upstream even if you are only a normal user of | ||
| Line 38: | Line 34: | ||
to the most recent version of the package in OE. | to the most recent version of the package in OE. | ||
= sample text for upstream reports = | == sample text for upstream reports == | ||
Hi, | Hi, | ||
| Line 48: | Line 44: | ||
openembedded.org project did to the sources you publish. | openembedded.org project did to the sources you publish. | ||
Patch: http://cgit.openembedded. | Patch: http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/$patch-url | ||
Comment: $explanation | Comment: $explanation | ||
You can find all our patches for $project at | You can find all our patches for $project at | ||
http://cgit.openembedded. | http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/ | ||
Thank you again for your work. | Thank you again for your work. | ||
Latest revision as of 10:40, 7 November 2012
Sourcing Patches
When you encounter problems with software, we're often not alone. For this reason its worth looking at other projects and seeing if they already have solved the problem (as well as checking if there is already a fix upstream). Good sources for patches are:
Patch Guidelines
Experience shows that whilst its clear in your mind why a patch is being added at the time you add a patch, if you revisit it a year later you probably won't remember all the details. For this reason, we ask that patches clearly state some basic information. The full details are available at Commit_Patch_Message_Guidelines.
Sending Patches Upstream
OE has many patches which for many reasons would be best submitted to the upstream projects rather than being maintained in OE itself. By doing this the wider community can benefit from the changes, recipe upgrading becomes easier and it also in many cases educates the upstream software projects about how their software gets used and for example, the challenges of a cross compile environment.
Push'em-weekends
These are sprints in the spirit of our bug-squashing weekends when we try to push our patches to the upstream projects. The first such sprint was held on short notice from Friday, February 15th 2008 to Monday, the 18th. A few patches were already pushed upstream. Second sprint is scheduled for first weekend in August.
Pushing our bugs upstream is beneficial for us (easier maintainability) and them (we give back our work). The following two commands can give you a list of patches still in need of being documented in line with above policy.
find recipes/ \( -name '*.patch' -or -name '*.diff' \) -print0 | xargs -0 egrep -L \^upstream\:
You can push those patches upstream even if you are only a normal user of OE. Let us know via the bug tracker if you have reported one of our patches upstream. Please be sure to test if the patch is still being applied to the most recent version of the package in OE.
sample text for upstream reports
Hi, thank you for sharing your work in $project. Openembedded.org includes recipes to cross-compile $project for a large number of target devices. I would like to make you aware of some of the changes that we at the openembedded.org project did to the sources you publish. Patch: http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/$patch-url Comment: $explanation You can find all our patches for $project at http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/ Thank you again for your work. Regards $name