On 17/08/10 23:38, Michael Hope wrote:
Hi Andrew. I'm confused - apart from a few differences, our methods seem to be the same.
The differences against Method 1 are:
- Every revision has an associated ticket
- There's a bot that automatically creates a ticket per revision
Yes, because these two differences are the basic requirements that we started with: that every change needs to be tracked, and that expecting real people to start the tracking process will lead to trouble.
Your tool to detect what tickets are associated with a revision comes up blank much of the time, and I don't see a way to fix it - not every revision uses --fixes, and even if it should it's easily forgotten.
- Final upstream status is tracked through the status field instead
of the milestone
No, my method uses milestones to show where a patch *should* go, and where it *has* gone. It differentiates between the two using the status.
I agree that we should automate creating tickets for untracked revisions. I wanted to get the rest in place before adding this.
The kernel guys made it very clear that they weren't interested unless it was automated. I take a similar view. If I have to add lots of extra bugs manually, then (a) I'll miss some, and (b) I'll get them wrong.
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
Yes, two revisions, two tickets. Keep it simple.
- If the change is a bug fix, we have to update two tickets - the
tracking and the original to show where it is fixed.
No, the bug fix will have a link to the tracking ticket. That's the only place that information needs to be.
- A fix which is upstreamed in 4.6 and backported to our 4.4 and 4.5
leads to duplicate tracking tickets
Again, two revisions, two tickets. Very simple, easy to understand. It's quite probably the two revisions are not the exact same patch anyway.
- 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
Yes, that's true.
There's a lot of ticket duplication there.
OK, here's a use case: I look at r123456, and I want to know what the upstream state is? How do I do that?
Method 1: if r123456 was a bug fix, and the committer remembered to use --fixes, then we're good. If r123456 does not have a ticket associated with it, what now?
Method 2: search launchpad gnu-linaro-tools bug tracker for "r123456"; there's guaranteed to be a match.
Regarding your comments,
The patch tracking comments might get lost among the other comments
Neither here nor there on this one
Imagine it's one of those bugs that has comments that go on forever. Ok, so you're looking for the upstream status, so you can do a search for it and find it. Now imagine that multiple commits were tracked against this bug; it's obvious that there are multiple when you search, but it's not clear which revisions have been posted upstream, and which have not - the follow up comments are hard to untangle, and rely on knowledge of what each patch does. Add to this that the bug got reopened due to a re-occurrence of the original problem, and it's going to be very hard to figure out.
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.
It's confusing because there will be multiple patches being tracked in parallel in the same comment thread. The initial tracking entroes might be clear enough, but the follow-up comments are likely to be hard to differentiate, at least for those not intimately involved with the bug fix. Presumably there will also be multiple "affects gcc-linaro-tracking" lines, and which is which? It'll be hard to find a definitive final state for each patch.
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.
It's certainly not the most difficult case, but there still potential for confusion here. Presumably even if the history is recorded in just one place, each bug still has an 'affects' that need updating.
(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.
I think our system is the exact same here, except that I suggested having multiple milestones in the "never" milestone.
Andrew