A universal bug-tracking wiki?

[the dsc]

Just a semi-random thought of someone who never dug deep into how the whole development and bug-tracking world works.

Wouldn't a wiki system be a "perfect" plataform for a unified bug-tracking system for linux distributions, other OSs like BSD, and GNU stuff? I can imagine that category and subcategory tags could be used to create a very intuitive and informative nested hierarchy/organization of bugs, according to OS, distribution, release, desktop environment, software, version, severity, and so on.

It may all be already quite nicely handled by the several independent bug-tracking systems, I wouldn't know, but I always find them confusing, almost intimidating, and certainly not as user-friendly as wikipedia.

Perhaps it's a matter of getting used to them, but still, there are the annoyances of having to have multiple accounts on several places, and perhaps, learning different details of each bug-tracking system.

Here's an article with some points about how a universal bug-tracking system is a much needed thing:

DistroWatch.com: Put the fun back into computing. Use Linux, BSD.



What are the main obstacles toward achieving something like that? It' something we're likely to see in our lifetimes or not? And which is really the ideal bug-tracking plataform? Is there too much dispute over that?

[GNU-Fan]

The idea of being independent is strongly entrenched in most FOSS developers. This big, central bug-tracking sounds a bit like "cloud computing". Most developers want to keep everything project related under their own control.

Then there is the lack of volunteers who are committed to administrate such a project.

As a user, I agree that it is tiresome to create a new account for every new project you want to report bugs for. But I think there is method behind it.

As a developer, I personally prefer to get emails with bug reports. It is more personal. And people tend to put more effort into it because of this. Then I fill in the bug into the database myself with my own words. I would have to confirm and classify it later anyway. But this may work only with smaller project, which the developer has "personal bonds" to.

Lastly, I think that casual users had better report to distribution specific bugtrackers. The admins there can then decide if the bug is distro specific, and they can redirect the report in a distilled form to the regarding developers.
These distro bug trackers could be more newbie friendly, I admit. But I assume this is due to a undersized staff as well.

[the dsc]

That's an unexpected perspective. While I mentioned the "users won't need to have dozens of accounts in different places", my main thought was that it would be vastly more beneficial to developers.

The "independent" approach seems (it's not a judgement, I'm just telling what it "looks like" superficially to someone who can barely write his own bash scripts) quite messy. Looks like if someone decides to take care of a certain bug, he or she has to do a lot more of work researching in different bug-tracker systems, not only to see if it has already been dealt with, but in trying to find other possible relevant bits of information of various sorts.

While, perhaps in some magical ideal unified system, one could even have the data somehow thrown into some application with would draw a graph with correlations and such sort of things, perhaps coming up with a picture that makes more obvious some aspect that would be much more harder to find out.

But even without this magical graph-making application I just made up, the key differences I thought were the hierarchically nested context to where and how the bug is happening, not to mention less work with bug duplicates and other stuff that is not even exactly a question of solving the problem itself, but of management.