PDA

View Full Version : Public bug tracker for feature requests



Stephen A
09-11-2009, 07:38 AM
Khronos encourages developers to request features through this forum. This is far from ideal:

1. We need to request the same features over and over again with each release of OpenGL.
2. There is no good way to follow the discussion, evolution and current state of any single feature over time. Topics like "feature requests for OpenGL 3.0/3.1/3.2" mix all feature discussions together.
3. There is no good way to obtain statistics for features. For example, when was a feature first requested, how often is it requested and so on.

I understand that Khronos has direct communication pathways for vendors and corporate users (and that those carry more weight on the evolution of OpenGL than the opinions of independent developers), but a public bug/feature tracker would be more efficient across the board.

The ideal solution is something integrated with these boards (so we don't need separate logins). The second best solution is to "open up" the Khronos public bugtracker (i.e. make it publicly searchable on the web, add new categories for feature requests). Trusted members of the community can be involved in cleaning up reports and removing duplicates, to remove this burden from Khronos itself.

Is there interest in something like this? Would the powers-that-be consider implementing or opening up the public bugtracker?

Alfonse Reinheart
09-11-2009, 11:46 AM
There was a post in another thread about making a bugzilla-like database for GL driver bugs. This sort of thing could go there.


We need to request the same features over and over again with each release of OpenGL.

The ARB probably has the list of features we previously requested, assuming they're keeping track of this forum at all.


There is no good way to follow the discussion, evolution and current state of any single feature over time. Topics like "feature requests for OpenGL 3.0/3.1/3.2" mix all feature discussions together.

Perhaps people should stop making topics like that then.

Stephen A
09-11-2009, 12:32 PM
The ARB probably has the list of features we previously requested, assuming they're keeping track of this forum at all.

"Probably" and "assuming" is good enough - but only just. A public tracker would take care of the uncertainty and would help build an actual community to manage the flow of information.

Why is a community important? Because outside of the specs/drivers, OpenGL is community-driven: conformance tests, utilities, the vast majority of books - none of those are sponsored by Khronos.

Yes, the community has created conformance tests. Most are small, unfocused efforts, but Mesa is planning to create an inclusive testing suite as part of their OpenGL 3.x effort. The community has created utilities like GLEE, GLEW, GLUT, SDL, plus every single OpenGL language binding in existence. The community is maintaining the OpenGL wiki, writing books and tutorials on OpenGL - need I go on?

Any effort to strengthen the community will have a direct, positive impact to the OpenGL ecosystem. Khronos can - and should - take advantage of this.

See Sun's bug tracker (http://bugs.sun.com/) for a great implementation of this concept.


Perhaps people should stop making topics like that then.

Posts such as "talk about your applications" seem to be encouraged here. A common theme on topics seems to be, "say what you'd like to see in the next version, so we can take it into account".

Alfonse Reinheart
09-11-2009, 01:28 PM
A public tracker would take care of the uncertainty

No, it would not. It all depends on whether they actually care to look at it. Having a public tracker would not ensure that they look at it or plan anything based on it.

Jan
09-11-2009, 02:08 PM
Why not put up a side in the Wiki ? I mean whether i track bugs in a bug-tracking software or a wiki is really only a technical difference, the issue is the same.

However, i think it is not the software that is lacking. If we had a public bug-tracker, i assume it would vegetate along just as the wiki does. I think the problem is simply, there are many non-professional OpenGL users (beginners, people that need to visualize small data-sets, nothing fancy) and then there are a few "professional" OpenGL users (with professional i mean people who know it very well, whether they use it in their job is irrelevant).

The many non-professionals are simply not knowledgeable enough to help out in a community-based effort (wikis, the SDK, bug-tracker, ...) and the professionals have not much time to invest in such things. Other communities strive much more because they have an enormous user-base (Wikipedia) and/or they have a low entry-level of knowledge that one must accumulate before one can contribute, which means that many younger people with more time (pupils) will contribute.

OpenGL however has none of that, simply because 3D graphics is a niche in general and it is difficult to learn (sure, OpenGL itself is not THAT difficult, but you need to learn programming in general before you can start with it).

Therefore i don't think that "more community support" from the ARB will change much, because the community is not that much larger than the people posting regularly on this board. And most of those have no time to contribute (i don't).

So my advice: Go ahead, create a bug-tracking page in the wiki, see what happens. If it is used properly, one can still ask the ARB to create an official bug-tracker.

Jan.

Stephen A
09-11-2009, 02:34 PM
For all intents and purposes, the wiki is a worse medium for bug tracking than this forum. I can tell you flat out that the wiki will fail, simply because:
1. it is not discoverable
2. you need a separate login
3. noone from Khronos seems to care about it

Alfonse Reinheart
09-11-2009, 03:07 PM
i assume it would vegetate along just as the wiki does

Um, some of us are trying to improve the Wiki. It is only "vegetating" if you haven't been there recently.


For all intents and purposes, the wiki is a worse medium for bug tracking than this forum. I can tell you flat out that the wiki will fail, simply because:

There are a lot more reason than that.

Bugs, or worse requested features, do not fit into a Wiki model. You want to be able to track bugs and mark them fixed. You want to be able to search for specific classes of bugs. And so on.

Further, how would you differentiate between real Wiki content (ie: things OpenGL actually does) from things that someone wants it to do? How do you explicitly turn down a feature, or mark a bug as fixed? How do you search for bugs that haven't been fixed? And so on.

Wikis are not a good mechanism for bug/feature tracking.

I'm fine with the Wiki containing general information about such bugs and workarounds, but it should not be the ultimate repository of such knowledge.

Dark Photon
09-11-2009, 05:57 PM
For all intents and purposes, the wiki is a worse medium for bug tracking than this forum.
Probably. The wiki is not the ideal medium, the forums could be better, though MediaWiki is already set up on the web site, it is backed by a database, which "could" be used for issue tracking, turns out there are some issue tracking extensions out there for MediaWiki now (e.g. Extension:IssueTracker (http://www.mediawiki.org/wiki/Extension:IssueTracker) and Extension:BugSquish (http://www.mediawiki.org/wiki/Extension:BugSquish)) which might be decent, and enabling MediaWiki extensions is a snap.

However...


Further, how would you differentiate between real Wiki content (ie: things OpenGL actually does) from things that someone wants it to do? How do you explicitly turn down a feature, or mark a bug as fixed? How do you search for bugs that haven't been fixed? And so on.
Agreed. There are basic logistics questions (including the above) that must be answered before it even makes sense to talk about specific issue tracking systems:

What are the users of the database and intended uses?

What's the permission model look like: Who can create? Who can attach follow-up comments? Who can resolve? Who can verify? Who can delete? Who can search? Who has "god" privilege and can do all these things? Are any vendors gods (hope not)? Or is the whole thing "scouts honor, I won't delete things I shouldn't and just mess with people".

Can we adequately attribute issues to specific driver vendors and multiple vendor release"s" (plural) per OS (since vendor versions vary by OS :sorrow:) so the community knows when they were encountered (vendor:OS:version) and when they were allegedly fixed (vendor:OS:version), and when they were independently verified (vendor:OS:version)?

Does it support attaching specific cross-platform test programs so that the bug can be cross-verified on other driver versions/OSs by other users and the vendor and verified fixed by users?

That said, it could be worth the effort! This would be a tremendous resource for the development community! Sure would beat random googling or searching GL forums and blogs here and there, particularly when your issue gets dropped into a vendor support black hole after you submitted it to the vendor.

This would also quantify the driver quality and maintenance responsiveness of the vendors, supporting or refuting the "Vendor X sucks, Vendor Y rules" heresay that pops up here occasionally. If the bug list doesn't support it, then it's just hot air.