Method for splitting one bug report into two
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Invalid
|
Low
|
Unassigned |
Bug Description
In short, need a mechanism to allow splitting out one user's comments from an existing bug, into a New bug, and then hiding their comments in the original one.
== Background: ==
Quite frequently in ubuntu we'll see bugs gain a number of "me too" comments from people other than the initial reporter. I suspect this is partly due to launchpad being a bit too free in suggesting possible existing bugs when a new bug is filed, but that's a separate issue. In any case, rather than file a new bug, the user will often just pick a bug that sounds similar if it roughly describes their problem, and say "I have this too".
Often, the user also fails to include necessary information (logs, error messages, stack traces, etc.) in the assumption that the bug has already been sufficiently well reported, and just assumes their confirmation might help in some way. (Of course, that's rarely the case, but nevermind for now.) We simply request they file a new bug report, and that's that.
However, *sometimes* the user will have done a good job of attaching all the necessary files, perhaps done some troubleshooting on their own, followed up appropriately, and otherwise is being a good bug reporter citizen, but they just happen to have a completely different issue than whatever was originally reported. Asking them to then redo everything into a new bug often feels a bit rude, yet having multiple distinct bugs glommed into a single bug report makes the bug report unwieldy.
== Example: ==
https:/
The original reporter had added enough info to troubleshoot the problem and upstream it. A second person has commented extensively on the bug, believing they have the same problem, however in reviewing it, they have extremely different hardware and different symptoms, and their case needs to be analyzed/upstreamed separately, and their comments have no bearing on the original report.
The second reporter has put in enough info that I could triage their problem too, but doing two bugs in one bug report is just too cumbersome. I could manually create a new bug for the user, but I don't want to spend the time, and plus it's better if the bug report is filed by the person seeing the bug.
== New Feature: ==
The new feature would allow a bug triager to split one user's comments out into a fresh new bug, owned by that user. The user's first comment in the original thread would be set as the bug description, and subsequent comments would be entered as comments. Any attachments they filed would also be copied over. The original bug report's description would be included in the new bug description, but marked as "quoted" in some fashion. It's expected that the triager splitting this bug out would probably need to tidy up the description a bit further.
In the original bug report, their comments would be collapsed to be hidden, making the bug a bit easier to follow. An 'expand' link would allow people to see these comments, just in case there's question.
Changed in launchpad: | |
status: | New → Triaged |
Changed in malone: | |
importance: | Undecided → Low |
tags: | added: feature |
Hmm
i also wrote that it should be cool splitting and merging bugs in
Heres problem with merging bug 432881 is reported as fixed. but its not. bug 458148 aprowes that.
so if fisrt bug is made as dublicate what would happen to last comment? If its merged in then it would make confusion couse in the middle someone says its fixed.
If no better solution comes then merging has problems but in splitting i dont see any problem. Just select witch comments are for witch bug.
Or acctually if one bug has many bugs then they shouldnt be splitted and finished in same bug report if both bugs in one report are easy and solved.
But sometimes splitting would help especially if bug fixing takes longer time..
+1 for splitting.