Re: Patch tracking method
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: > 1. Every revision has an associated ticket > 2. 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. > 3. 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 thi
Re: Patch tracking method
On Wed, Aug 18, 2010 at 8:11 PM, Andrew Stubbs wrote: > 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: >> 1. Every revision has an associated ticket >> 2. 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. Agreed. Both methods achieve that. Method 1 currently uses a report to show what is missing but will have a tracker bot added. > 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. You can tell which revisions are untracked by the patchtracker report at http://ex.seabright.co.nz/helpers/patchtrack. Revisions that are currently untracked can be added to an existing ticket by adding a one line 'related:' comment to that ticket, or via a tracker bot. Future work will typically use the --fixes line. >> 3. 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. Sorry, by 'should go' do you mean the ideal upstream location such as 4.6, and by 'has gone' mean where it ended up, such as 4.6 or in the rejected list? > 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. We shouldn't manually add tickets for new features. The patchtracker report ensures none are missed. >> 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. ...but one original piece of work. We won't spread things like this, but say we wanted to add feature X which was spread across five commits. If we have one ticket then we can easily answer the question 'what is the state of X' by checking one ticket instead of 5. >> * 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. Say the bug was found in Firefox but caused by GCC. How can the original reporter easily tell the status of the ticket? If there are two tickets, one for the bug and one for the revision, then something has to slave the bug status off the revision status. >> * 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. Agreed. >> * 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? Either the tracker bot creates a new ticket, or you add the one line comment 'related: ...' to the bug that it fixes. The revision and bug are now linked. >> 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. I agree that on messy fixes we should have multiple tickets to track separate upstream patches. Both methods allow this. Method 2 requires this. >>> Bugs that produce multiple commits will have to be tracked multiple >>> times, which is just confusing
Re: [Bug 620229] [NEW] [4.5:r99360] Code hoisting improvements
Sorry about these. Hopefully I'm done. On Thu, Aug 19, 2010 at 2:28 PM, Michael Hope <620...@bugs.launchpad.net> wrote: > Public bug reported: > > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > ** Affects: gcc-linaro > Importance: Undecided > Status: New > > ** Affects: gcc-linaro/4.5 > Importance: Undecided > Status: New > > > ** Tags: revision > > -- > [4.5:r99360] Code hoisting improvements > https://bugs.launchpad.net/bugs/620229 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in Linaro GCC: New > Status in Linaro GCC 4.5 series: New > > Bug description: > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/gcc-linaro/+bug/620229/+subscribe > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Patch tracking method
I've had a go at adding the basic trackerbot functionality to: http://ex.seabright.co.nz/helpers/patchtrack This page lists all revisions on a branch. Any revisions that don't have a corresponding ticket are marked in orange and have a 'Create one' link. Clicking this link takes you to a pre-filled out form that will then create the ticket. It's a manual process at the moment as I wanted to sort out the formatting and content of the tickets before having the bot do it automatically. Note that the database behind this only updates once an hour. If you make a change you unfortunately won't see the effect for some time. Thoughts? -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
