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