Saturday, March 24, 2007

OpenSolaris priorities

Before the OGB election there was the OpenSolaris Comunity Priorities vote.

Looking at the result, and the clear winner in terms of priorities is the public defect management system. Yep, I put that at number 1 too. (I think...)

The OpenSolaris Bugs interface did get revamped recently, and that was a significant improvement. However, it's still not really doing anything for OpenSolaris - it's just a way to give a limited view of a subset of Sun's bug database.

Importantly, there's no other integration with anything else the community might be doing, and no way for a community member to interact with the system. How can it be improved?

Here are a couple of things I would like to see:

Eliminate all the crud. The database is littered with all sorts of things that aren't bugs, and still contains bugs that are antique. We need to take some of the open bugs forward, but most of the database has no relevance to the current codebase.

I think this means we need a completely separate database. And bugs that Sun generate through their support organization need to be put into the public OpenSolaris bug database the same way that Sun currently logs bugs against external projects such as Gnome.

We need to allow community members to participate in the triage process, and allow comments and followups to further refine the bugs and provide sample solutions, test cases, and prioritization. This extra interaction will build a stronger community, and provide ways for more people to get involved.

And the database needs to be linked into the whole workflow, so that there's a way to see who might be working on a particular bug and contact them.

The bug database is the crucial missing link. We want to improve and develop OpenSolaris, and to do that we first need to know what's broken and what's missing.

2 comments:

Anonymous said...

Removing old bugs (or closed bugs, or anything else) is bad.

Bugs are part of history, even closed, old or fixed bugs contain information that can (and will) be of value.

-- Rich

Anonymous said...

I don't think you've thought these ideas very much. Sun's support organisations are not allowed to make all their information public. Care to think about how many national Privacy Acts and Directives that would break? Just not worth it.

Another problem (apart from the history, which Rich pointed out) is that "separate" translates really really fast to "completely ignored and unused by those who you really want to use it." Defeats the purpose if you add another layer of process and infrastructure.

The third problem (and one which I'm very familiar with) is that when Sun arranges to provide support for new hardware which they are reselling, the OEM almost always does not want data about their products made visible to all and sundry - slight matter of intellectual property which they get touchy about.

I do like the idea of having more people involved in triage and issue reproduction, but the community as a whole is going to have to think of a much better solution than what you've outlined.