Push patches upstream: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Outline =
= Sourcing Patches =  


OE has quite many patches that are just too valuable to keep to
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:
ourselves. OE encourages the following soft policy for adding patches
to the repository.


By the way, [http://patch-tracker.debian.org/ Debian], [http://patches.ubuntu.com/ Ubuntu], [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo] as well as [http://cvs.fedoraproject.org/viewvc/rpms/ Fedora] are of course always a great source for grabbing high-quality patches to include in OE.
* [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]  


= Policy =
= Patch Guidelines =


1) first line in a patch starts with '''upstream:''' and goes on to list the
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]].
    URL where the bug has been reported upstream or "OE-only" if the patch
 
    is just a hack or applicable only to OE.
= Sending Patches Upstream =
2) further information can optionally be listed in the following fields.
    Adding them is strongly encouraged where appropriate.
    * status: pending, accepted in XXX, rejected (upstream)
    * origin: where the patch has been stolen  ;-)
    * comment: any further detail such as description or reason for
              application of the patch


Take a look at [http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/busybox/busybox-1.9.2/adduser-longops.patch an example]
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 40: 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 63: Line 57:


[[Category:Policy]]
[[Category:Policy]]
[http://www.resumesplanet.com professional resumes]

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