BKMs for Package Updating
This page will be for capturing the BKMs of package upgrading as we get reviewed and process more of the packages.
Don't Retain older Versions
Unless there is a specific need (which will probably occur for GPLv2, this has also happened in the past when platforms have known bugs in the latest version) don't retain older versions of the recipe files and patches.
Use git mv to rename recipe and patches
From Josh: Generally the way I perform recipe upgrades is to use git mv to rename the old file to the new version, this means that you don't have to consciously delete the old version later (win 1) and that git tracks the rename and the differences with the old file, which doesn't happen with a delete and add (win 2).
The advantage of this is that you and any reviewers can more easily see what has changed with the updated version of the recipe.
Nitin: Actually {git mv a b} is nothing but {mv a b; git rm a; git add b} And the file renames are detected by git automatically by looking at the file contents. Because of this git behavior, git shows some renames as renames and sometimes not. And I did not find a way to force git to understand renames. So if after "git mv" git is showing "file add & file remove", then don't get surprised, it's normal git operation.
Reset PR to 0 (or add PR) when upgrading recipes
This is a good visual reminder to bump in the future if needed.
For upgrades it's ok to use OE for inspiration
When upgrading packages, do the git mv as above, and build if it breaks, it's OK to check the OE equivalent and grab new patch or configuration change, just don't grab the whole recipe.
Be sure to add a credit to OE in your commit message when you do take a change like this.
Review: Merging packages from OpenEmbedded
For new package grab OE version, but sanitize them
Follow the recipe rules for Yocto when you take an OE recipe, be sure to clean all the OE'isms out
Again, give credit to OE in commit messages
