Automated bug comparisons

[SorinN]

mr. Duncan

good ideea. my feisty trow me some crash reports right when ..let say
- I'm not prepared to deal with bugs, maybe when I close some programs
before shutdown(because I just have to go to the meeting). then - U
will agree - is not the perfect time to search for duplicates. in
general - peoples will skip this step because they're not Linux geeks
at all and bug trackers are alien tech for them - especially when is
for the first time(to sign a bug).

second idea. well, I don't have all time at my disposal ( me and
..unhappy few others ). I wanna help,  but the report tools and
trackers must be prepared to eat this huge amount of data - without
loosing my time to classify my bug. else the linux cause will loose
again a hero. one per day / minute / sec - who knows ?.

3. a bit of abstraction + some intelligence pumped to the track tools
- will not hurt  anyone.

Sorin



2007/3/27, Duncan Lithgow <dlithgow at gmail.com>:
> I expect:
>
> * The new bug reporting tools will result in a much larger stream of bug
> reports after Feisty's release.
> * A large number of new bug reporters will start by filing automated
> bugs without searching effectively for duplicates.
>
> Therefore: the number of duplicates is going to rise.
>
> This got me thinking that the machine looking after launchpad (or even
> as a distributed computing project!!) should be able to compare and flag
> reports with a score rating the likelyhood that they are a duplicate of
> another bug. This would make finding duplicates more effective - it
> could of course also be given a very low priority on the machine(s)
> serving launchpad so it effectively uses spare CPU power.
>
> Is this plausible/ sensible? Anybody want to take the idea further?
>
> Duncan
>
> --
> launchpad-users mailing list
> launchpad-users at lists.canonical.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/launchpad-users
>
>
>


-- 
Nemes Ioan Sorin