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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
