On Fri, Aug 13, 2010 at 11:06 PM, Loïc Minier <loic.min...@linaro.org> wrote: > On Fri, Aug 13, 2010, Andrew Stubbs wrote: >> > I think it's relevant to consider two things around this tracking: >> > - we're tracking a feature or a bug fix >> >> There's no automatic way to determine this, but it could be tracked >> using launchpad tags. Updating the tags might be tedious though. >> >> > - we want to track updates to this new feature or this bug fix >> >> Again, there's no automatic way to do this, but it's easy enough to do >> it manually. We would modify one of the tracking tickets to reference >> both parts of the patch (and close the other ticket, or mark it a >> duplicate). > > Sorry, wasn't clear, the part of my email which you quote above was > meant to underline the properties of the patch tracking system that I > care about rather than suggesting a design. The bottom of my original > email has more ideas on how we could make sure we don't miss anything. > > Before we dive into implementation questions such as Launchpad tags, or > tickets, or new software to be developed, I think it's important to > understand the fundamental goals of the tracker and the data it would > be working on. > > I personally think the processes should act on upstream mailing-list > threads, on upstream checkins in various branches, and on our checkins > in our branches. Launchpad bugs/tickets could indeed play an important > part of that, but I suspect we'll need more on top of Launchpad, and > the relation might be anywhere from zero Launchpad bugs for a patch > which is in Linaro and upstream, up to many bugs for a single feature > getting developed upstream, then backported to Linaro, or vice-versa. > > For instance, we want to make sure we review all upstream commits and > all upstream emails with patches, but we might not want to open one > bug/ticket per upstream email or email thread.
I'm worried about this getting too big. Our immediate needs are: * Being able to send patches upstream and track what happened to them * Being able to do work upstream and track the upstream version where they landed These two together lets us track what patches need to be brought forward on a rebase. I wrote up the basic classes some time ago: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking It's done as a set of reduced classes as they're easier to understand than use cases. This captures the case where patches are accepted as is, modified before landing upstream, or rejected. It doesn't handle patches later being refined or obsoleted but that is outside scope and can be treated as a new feature. There's a separate question about tracking other upstream changes and deciding what to backport. We shouldn't backport everything, only those that have either a performance gain or clear correctness gain. Implementation-wise, I can see two good uses for Patchwork: * It provides a rolled-up summary of any of our patches. Easier than trawling through notes on a Launchpad bug * It (may) provide a shared way of making sure we've reviewed every patch for a potential backport. Note that reviewing upstream patches for backport is a new feature and outside the scope of the Linaro patch tracker. -- Michael _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
