The patch tracking conversation has got a little out-of-hand, and I know I've misunderstood some of the features Michael has been proposing, and I suspect vice versa.
So, here's my attempt to compare and contrast the various advantages, disadvantages, and differences of the ideas so far, by means of use cases.
Looking at this, I think we can probably come up with a solution that uses the good bits from each (maybe method 1 with the milestone/status policy from method 2, for example).
Please read the below, and let me know if I left anything out, or if I misunderstood something.
Andrew
====
For the purposes of this document:
* Method 0 is my original patch tracker, here:
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.5UpstreamPatches
* Method 1 is Michael's proposed patch tracker, here:
https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%201 and here: http://ex.seabright.co.nz/helpers/patchtrack
* Method 2 is my proposed system, here:
https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%202
--------------------------------------------------------- 1. What does a user have to do to get a patch tracked?
Method 0:
Nothing. New rows are added to the wiki page regularly by a script and cron-job.
Method 1:
Nothing. The tracking report is updated regularly.
Method 2:
Nothing. New tickets are created automatically, regularly.
------------------------------------------------------------ 2. How to find tracking information for a revision?
Method 0:
Search the wiki page for the revision number.
Method 1:
Goto the report page, click through to all the various associated tickets, if any.
Method 2:
Go to launchpad, and search for "r123456", or select it from the list in the relevant gcc-linaro-tracking milestone.
------------------------------------------------------------ 3. How to find tracking information for a bug fix?
Method 0:
Search the wiki page for the bug number - hopefully somebody has posted a link. Alternatively, the first line of the commit message will be present. If that doesn't work, then find the revision number by other means (bzr).
Method 1:
Go to the bug ticket - it should be there, or a link to another bug that has it. Alternatively, go to the tracker report page, and search for the commit message. If that fails try to identify the revision number by other means (bzr)
Method 2:
Go to the bug ticket - if the bug was committed with --fixes, there will be a link to the tracking ticket. Alternatively, search gcc-linaro-tracking to find the commit message. If that fails try to identify the revision number by other means (bzr)
---------------------------------------------------------- 4. How to add new tracking information?
Method 0:
Edit the wiki page.
Method 1:
Add the new information to one or all of the associated bugs, if any. If there are no existing tickets, create a new ticket (using the link on the tracker report) and put the information there.
Method 2:
Add the information to the ticket.
----------------------------------------------------------- 5. How to indicate that the bug is upstream?
Method 0:
Edit the wiki page, set the bgcolor to green.
Method 1:
Assign all the bug tickets to a gcc-linaro-tracking milestone.
Method 2:
Mark the bug "Fix committed". Ensure that the ticket has the correct milestone.
------------------------------------------------------------ 6. How to list all patches that need to go upstream?
Method 0:
View the wiki page - the patches are highlighted in red and yellow.
Method 1:
View the tracker report - the patches are highlighted in red, yellow, and orange.
(Note that launchpad will only list the patches that already had a ticket attached, or else somebody has create one. This will usually only include patches where somebody had something to say about it.)
Method 2:
All open bugs in gcc-linaro-tracking.
------------------------------------------------------------- 7. How to list all patches that need forwarding on rebase from 4.5 to 4.6?
Method 0:
Any patches marked in red or yellow on the wiki page need forwarding. Any patches marked in green with an upstream landing number of 4.7 or higher also need forwarding. (This information is not yet encoded in the page, but it's a wiki, so flexibility is not a problem.)
Any patches in grey also need considering. Some are uninteresting version bumps and such. Some are patches we plan to carry forever. Probably a new colour could be used to make this clearer - it's a wiki.
Method 1:
Any patches in the report not yet upstream need forwarding. Any patches in launchpad against the 4.7 milestone (or higher) also need forwarding.
Any patches in the "never" milestone also need considering. Some might be ancient patches we used to carry in 4.4, but have since been dropped. Some will be patches we intend to carry.
Method 2:
All patches against the 4.7 milestone, both open and closed (modify the launchpad search criteria) need forwarding. All patches in the "series:never,milestone:4.5" milestone in the "won't fix" state need forwarding.
(Patches we don't intend to carry forward will be "closed", and patches from 4.4 won't be in "series:never,milestone:4.5", so we never have to worry about those.)
------------------------------------------------------------------ 8. How to we track what patches have been forwarded on rebase already?
Method 0:
It's a wiki, add a column.
Method 1:
Committing the patch on a new branch will (with --fixes) will cause launchpad to list the commit on the bug page. There's no way to query this though.
Method 2:
Committing the patch on a new branch will give a "new" patch to track. The trackerbot will create a new ticket for this revision. The old ticket will be marked as a "duplicate" of the new one (manually, or automatically). The new bugs will have "4.6/r123456" in the subject line, so can be easily be differentiated.
----------------------------------------------------------------- 9. What else needs doing on a rebase?
Method 0:
Create a new page with a new table. Forward the information from the old table manually, by editing the wiki.
Method 1:
Create a new tracker report.
Method 2:
Set up the trackerbot on the new branch.
------------------------------------------------------------------ 10. What prompts users to use the system?
Method 0:
Nothing. (Management nagging.)
Method 1:
Nothing mentioned so far.
Method 2:
The bug is always assigned to somebody. They'll be notified by email, and it will show up on their launchpad pages.
------------------------------------------------------------------ 11. What happens when a bug produces multiple patches?
Method 0:
Multiple lines in the table, initially. But, it's a wiki, so they can be edited, moved around, and coalesced as required.
Method 1:
The same bug has to track multiple patches.
????? How does that work with the 'affects gcc-linaro-tracking' lines?
Method 2:
One ticket per commit. Each is tracked separately, but the user is free to mark each ticket as a duplicate of the other, and/or move the data from one ticket to another.
------------------------------------------------------------------ 12. What happens when one commit fixes multiple bugs?
Method 0:
Nothing special.
Method 1:
Multiple bugs will track the same submission process. Either the user must post all the data to all the bugs, or one bug must get (manually) appointed the master bug, and the others have links posted.
Method 2:
One ticket will be created to track the patch. The ticket will contain links to all the bugs, and each bug will contain a back-link. This is very little different to the normal case.