On Fri, Aug 13, 2010 at 2: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
patchwork[1][2][3] can already monitor mailing lists for patches and is used by several projects (Linux kernel, various sub-system maintainers, etc.) to make sure that patches posted to the mailing list are not dropped. (cc'ed Jeremy, author of patchwork) Patchwork can also track updated patchsets and keep related patchsets (V1, V2, V3, ...) together, I believe. What would be very useful is patchwork on steroids that can track pre-configured upstream git trees and figure out which patches already landed in those trees (with tag info). This could be done by searching based on author, commit one-line description and detailed description and perhaps even the contents of the commit itself. This info that then be automatically updated in the patch tracker. The hard problem is when a commit goes upstream is a different form, by a different author, etc. > 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. [1] http://ozlabs.org/~jk/projects/patchwork/ [2] patchwork.ozlabs.org [3] patchwork.kernel.org _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
