Push patches upstream: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
No edit summary
No edit summary
 
(19 intermediate revisions by 6 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.


= Policy =
* [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]


1) first line in a patch starts with upstream: and goes on to list the
= Patch Guidelines =
    URL where the bug has been reported upstream or "OE-only" if the patch
 
    is just a hack or applicable only to OE.
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]].
2) further information can optionally be listed in the following fields.
 
    Adding them is strongly encouraged where appropriate.
= Sending Patches Upstream =
    * 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


You can find a sample at
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.
http://www.openembedded.org/repo/org.openembedded.dev/packages/busybox/busybox-1.9.1/adduser-longops.patch


= Push'em-weekends =
== Push'em-weekends ==


These are sprints in the spirit of our bug-squashing weekends when we try to  
These are sprints in the spirit of our [[bug days|bug-squashing weekends]] when we try to  
push our patches to the upstream projects.  The first such sprint was held  
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  
on short notice from Friday, February 15th 2008 to Monday, the 18th.  A few  
patches were already pushed upstream and we hope to do such a sprint again,
patches were already pushed upstream.  Second sprint is scheduled for first weekend in August.
soon.  Stay tuned.


Pushing our bugs upstream is beneficial for us (easier maintainability) and
Pushing our bugs upstream is beneficial for us (easier maintainability) and
Line 33: 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 packages/ -name *.patch -print0|xargs -0 egrep -vl \^upstream\:
  find recipes/ \( -name '*.patch' -or -name '*.diff' \) -print0 | xargs -0 egrep -L \^upstream\:
find packages/ -name *.diff -print0|xargs -0 egrep -vl \^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  
OE. Let us know via the bug tracker if you have reported one of our patches
OE. Let us know via the [http://bugs.openembedded.net bug tracker] if you have reported one of our patches
upstream.  Please be sure to test if the patch still is still being applied
upstream.  Please be sure to test if the patch is still being applied
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,
 
thank you for sharing your work in $project.  Openembedded.org includes
thank you for sharing your work in $project.  Openembedded.org includes
recipes to cross-compile $project for a large number of target devices.
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  
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.   
openembedded.org project did to the sources you publish.
 
   
  Patch: http://www.openembedded.org/repo/org.openembedded.dev/packages/$project/$patch-url
  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://www.openembedded.org/filebrowser/org.openembedded.dev/packages/$project/
http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/$project/
 
Thank you again for your work.
Thank you again for your work.
 
Regards
Regards
 
$name
$name


[[Category:Policy]]
[[Category:Policy]]

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
Retrieved from "https://www.openembedded.org/w/index.php?title=Push_patches_upstream&oldid=5141"