Hi Andrew. I'm confused - apart from a few differences, our methods seem to be the same.
The differences against Method 1 are: 1. Every revision has an associated ticket 2. There's a bot that automatically creates a ticket per revision 3. Final upstream status is tracked through the status field instead of the milestone I agree that we should automate creating tickets for untracked revisions. I wanted to get the rest in place before adding this. I'm not concerned on (1). There are a couple of problems vs re-using an existing ticket: * Two related revisions (such as the update changelog/bump revision pair done on a release) lead to two tickets where they could be one * If the change is a bug fix, we have to update two tickets - the tracking and the original to show where it is fixed. * A fix which is upstreamed in 4.6 and backported to our 4.4 and 4.5 leads to duplicate tracking tickets * Work which is done upstream starts with a ticket to track the work and email messages, then is commited to ours and perhaps backported, leading to three tickets with identical state There's a lot of ticket duplication there. (1) does have some advantages: * The original ticket isn't polluted with things the reporter may not care about, such as the FSF toolchain it is fixed in Regarding your comments, > The patch tracking comments might get lost among the other comments Neither here nor there on this one > Bugs that produce multiple commits will have to be tracked multiple times, > which is just confusing. Why is this confusing? Each patch is committed with a --fixes=... and is work against fixing that bug. Note that most work will be done in topic branches, so in many cases there will be one final tracked commit to the trunk. > Commits that fix multiple bugs are not straight-forward In what way? The commit has multiple --fixes=... lines for each bug that it fixes. Each original bug then has a record of when it will be available upstream. This does mean that one should be the 'master' which has the upstream patch history, and the others should be marked as such. (3) is neither here or there. I'm abusing the milestone system to give more information. Yours is fine - we can always add tags if it turns out more information is useful. -- Michael On Tue, Aug 17, 2010 at 10:28 PM, Andrew Stubbs <a...@codesourcery.com> wrote: > On 17/08/10 10:39, Andrew Stubbs wrote: >> >> I'm going to write a "method 2" to explain what I need/want. > > Now done: > https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%202 > > Andrew > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
