Patch tracking method
michael.hope at linaro.org
Tue Aug 17 23:38:57 BST 2010
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
(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.
On Tue, Aug 17, 2010 at 10:28 PM, Andrew Stubbs <ams at 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:
More information about the linaro-toolchain