There are many more readers than members

[HokTar]

Hmmm, interesting. Now I can see your dilemma and how my questions were "wrong". So yeah, you gave me the answer I was looking for.

On the other hand, if this is the case than probably the devs themselves should take their time and write a blog post every (other) week shortly describing what they are working on and what is the purpose/aim of that. I mean really, 5-10 sentences wouldn't hurt and take away the time from coding!
I try to give an example: Marek has submitted a lot of code recently for the r300g driver as git shows. But I'm an end user so the git commits don't give me much information on the benefits of the commits. They shouldn't either as that is not the purpose of them. But still, some more insight on a less techie level to what is going would be nice.

Just writing this stuff I realised that most probably it is Phoronix which I am wishing for. Maybe I just got dragged in too deeply into these matters that the flow of information from Michael is not enough...

As a sidenote it is good to be back on the interesting stuff!

[darkphoenix22]

Sounds to me like you guys need a much better development framework. I have mentioned Launchpad before, but there are other good ones such as GNU Savannah, GitHub, and Google Code.

In order to reap the full benefits of open source development, you must have a clear roadmap and development structure. It seems like you are reaching the limits of git and mailing lists. People need to know what to code and what to test in order to contribute and your current system makes it exceedingly hard to do so.

Perhaps look into putting each of these features (such as KMS, DRM and Mesa) onto different branches and split up the development tree among them. Periodically merge the braches to creaste new builds.

The Radeon drivers are also seriously lacking in end-user documentation. Perhaps put up a FAQ for users to read and list all the problems and pitfalls they may encounter. Distributions are great, but they can't do all the documentation and testing for you. You have to put a system in place to allow your end users and testers to contribute as well. And right now, frankly there isn't much of one.

[bridgman]

"That, detective, is the right question. Program terminated."

It sounds as if maybe it's time for TIRDC (The Irregular Radeon Development Companion) to come back to life now that the Great Architectural Transition is largely done and everything is kinda going back to normal development again.

I'm guessing that you're looking for something like :

http://tirdc.livejournal.com/21826.html

Does that seem about right ?

[darkphoenix22]

About there. Maybe make up a proper web page for the drivers to. Modern CMS frameworks make it stupidly easy to make and maintain complex websites. I can and will be willing to help out.

I highly recommend Drupal as it is the most configurable and flexible of the frameworks, but it is a bitch to learn. Huge websites such as http://www.whitehouse.gov , http://www.economist.com , and http://www.ubuntu.com all use it.

If you want a tech demo, check out http://infinityos.net . I basically made that web page in three days. I've honestly barely scratched the surface of what is possible with Drupal. Hell, I got lazy and just used the default theme.

[bridgman]

Sounds to me like you guys need a much better development framework. I have mentioned Launchpad before, but there are other good ones such as GNU Savannah, GitHub, and Google Code.

In order to reap the full benefits of open source development, you must have a clear roadmap and development structure. It seems like you are reaching the limits of git and mailing lists. People need to know what to code and what to test in order to contribute and your current system makes it exceedingly hard to do so.

Perhaps look into putting each of these features (such as KMS, DRM and Mesa) onto different branches and split up the development tree among them. Periodically merge the braches to creaste new builds.

Not sure I agree there. You are describing systems to let large numbers of developers collaborate efficiently on large projects without getting in each others way. Graphics driver development is more like the opposite situation - 20 or 30 projects that need to be done, each with a fraction of a developer at best.

IMO the top priority is documentation and infrastructure which could help potential new developers decide if this is an area where they could enjoy working. If we can double or triple the number of active developers then we might get to the point where co-ordinating their activities made a difference, but I think we have a long way to go before we even get to having 1/2 a part time developer for each initiative.

The Radeon drivers are also seriously lacking in end-user documentation. Perhaps put up a FAQ for users to read and list all the problems and pitfalls they may encounter. Distributions are great, but they can't do all the documentation and testing for you. You have to put a system in place to allow your end users and testers to contribute as well. And right now, frankly there isn't much of one.

I do agree with this one, although with a twist. There are already dozens of these systems in place, one for each distro, all active but all imperfect in their own way (mostly out of date info). I do think users would be better served by a single system with sections for distro-independent and distro-specific information.

[darkphoenix22]

Not sure I agree there. You are describing systems to let large numbers of developers collaborate efficiently on large projects without getting in each others way. Graphics driver development is more like the opposite situation - 20 or 30 projects that need to be done, each with a fraction of a developer at best

True, but these systems also scale down gracefully as well.

Here's my description of Launchpad on my website (which applies to the other systems as well):

infinityOS has a project at Launchpad, a website that integrates bug fixing, feature planning, commiting code, and answering questions into a simple easy to use UI. All you need to do to participate in infinityOS' development is sign up for an account.

In order to get developers working on your project, you have to make it that easy to commit code and document it. A system such as Launchpad and the others would allow you set one up in a matter of an hour. Hell most of them allow you to import Git code, with all the branching and commenting attached.

[bridgman]

Let me ask around. My sense is that the challenge of understanding the code, hardware and problem domain is an order of magnitude more significant than the challenge of dealing with basic git and bugzilla functions, although I'll be the first to admit that initial use of git involves more "chanting of carefully memorized incantations" than working intuitively.

Some of the problems that a system like Launchpad solves, however, are mostly problems of scale, so to a large extent different sized projects need to focus on different problems. Right now the open source driver community's biggest challenge IMO is the relative hostility of the technical environment - complex, performance-critical code shared across a variety of different GPU architectures,where a significant percentage of the common errors result in the same symptom - a locked-up GPU.

I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.

[darkphoenix22]

Some of the problems that a system like Launchpad solves, however, are mostly problems of scale, so to a large extent different sized projects need to focus on different problems. Right now the open source driver community's biggest challenge IMO is the relative hostility of the technical environment - complex, performance-critical code shared across a variety of different GPU architectures,where a significant percentage of the common errors result in the same symptom - a locked-up GPU.

I'm actually wondering if a GPU simulator might be the biggest single contributor to lowering the entry threshold for driver development.

Clarity and transparency are always your best friend.

I'm going to quote the Cathedral and the Bazaar, which is the open source development bible:

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." or "Given enough eyeballs, all bugs are shallow."

Even if people won't be directly contributing code, such a system would enable testers to more easily find bugs and allow you to fix them. You won't have the problem that was mentioned in the first post of this thread, where someone has found a bug, but didn't want to learn the system to file it.

In order to fix bugs, your testers have to be able to report them so you know about them. You want as few technical barriers as possible between your testers and your bug tracking system.

----------

As an aside, I recommend you read over the Cathedral and the Bazaar (if you haven't already). It is free online and pretty short (20ish pages).

Implementing each "law" it contains will streamline your project and make development much faster and easier.

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/

[darkphoenix22]

Just to make it easier for you, as I'm sure you're short on time, here's a law of the laws in the Cathedral and the Bazaar (though some of them admittingly do not apply to this project):

1. Every good work of software starts by scratching a developer's personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. Plan to throw one away; you will, anyhow.
4. If you have the right attitude, interesting problems will find you.
   [*[When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
5. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
6. Release early. Release often. And listen to your customers.
7. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
   [*[Smart data structures and dumb code works a lot better than the other way around.
8. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
9. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
10. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
11. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
12. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
13. When writing gateway software of any kind, take pains to disturb the data stream as little as possible?and never throw away information unless the recipient forces you to!
14. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
15. A security system is only as secure as its secret. Beware of pseudo-secrets.
16. [b}To solve an interesting problem, start by finding a problem that is interesting to you.
    Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.[/b]

I've bolded some of the laws for good measure.

[darkphoenix22]

Gah. I REALLY hate the edit limit on this forum.