Patch tracking

[Loïc Minier]

On Fri, Aug 13, 2010, Michael Hope wrote:
>  * Do a change upstream in 4.7, backport it to our 4.5, and backport
> it to our 4.6 when we make one
>  * Do a change locally, track where it lands upstream, and figure out
> what we have to bring forward when we next rebase
>  * Track what is Linaro specific and can't go upstream so we know what
> to bring forward

 I think it's relevant to consider two things around this tracking:
 - we're tracking a feature or a bug fix
 - we want to track updates to this new feature or this bug fix

 I know I keep repeating this, but I *really* want that to be taken into
 account: patches go through multiple revisions, and new features are
 often tweaked after being checked in.

 Of course we can consider commits after a feature has landed as
 unrelated bug fixes, but it kind of makes sense to group them together
 if we can, when preparing a backport for instance: this allows the
 backport to benefit from all known fixes which landed after the
 feature.
   For multiple revisions of the same patch, what I mean is that we
 might be pulling a patch from the upstream ML before it's committed,
 but then it get tweaked slightly and we want to pull that change, even
 if the patch was only ever committed once to the upstream repo.
   Another instance of this is when we are writing a patch locally, then
 upstreaming it: it might be committed in a slighlty different form, and
 we might want to update our local copy (or not), but in any case we
 want to check.


 Perhaps what could work are:
 - distributing reviews of new checkins to upstream branches, making
   sure new tickets get opened when a new thing shows up that we want to
   grab, or updating an existing ticket when there's already a related
   one
 - distributing reviews of upstream MLs to identify new stuff to grab,
   or to propagate updates to patches we might have cherry-picked from
   the ML
 - having a process for checkins of our local new features / bug fixes,
   making sure they are pushed to all relevant upstream branches

 After writing this up, I feel that writing the tool might be one hard
 thing, but getting the processes right seems quite hard too.

-- 
Loïc Minier