From: Ian M. <sp...@ar...> - 2002-05-14 21:56:52
|
Hi. It has come to my attention that the DRI website is, well, lacking. I'd like to offer my services in bringing it up to a nicer standard. Who should I be working with on this? |
From: Ian M. <sp...@ar...> - 2002-06-15 17:49:05
|
Just to let you know I havent disappeared. I have been rather busy, but have some time to update the website now. I know I have been given access to /something/, but I dont know what, nor do I know where or how to access the webspace. can someone contact me with the relevant information please? Thanks. |
From: Ian M. <sp...@ar...> - 2002-06-24 23:09:27
|
Hi. Well, thanks for your comments. Just to lay some fears / concerns to rest... 1) It isnt done yet! :) 2) I have yet to add text nav to the main page 3) The status page is going to disappear permanently, to be merged with the hardware page. All will becoime clear ;-) (and things that arent hardware related will go on a 'news' page.) 4) the resources page will be reorganised and split into user and developer sections. 5) dangling / self referencing links are either bugs, or, more likely, simply not fixed up yet. I will ask later for people to find dangling links, when the unfixed up ones are sorted. This includes the help us link. 6) A link to sourceforege project page will be added. 7) I will try and make sure all new developers read up and dont pester ATI for specs... ;) 8) I see no harm in the DRI logo being a link to home. I'll fix it up. 9) I'll add sourceforge (And other sponsor / partner logos as I get to them. 10) Anyone who wants can suggest stuff that needs copyright notices slapped on it. 11) comment about frameset backround is noted. The goal is to: (in no particular order) 1) Make the site look that bit more 'polished' 2) Make it easier for USERS to get what they need (without them, why are we bothering?) 3) MAke it easy for developers to get their stuff too (without them, we wouldnt need users!) 4) General spring cleaning. Happy hacking! :) |
From: Smitty <sm...@we...> - 2003-08-10 10:38:01
|
Been real busy lately, so I'm going to unsubscribe from dri-users, and filter out bugzilla-daemon to delete without reading. Otherwise I just won't be able to read all the posts, this makes it a third less emails I have to read. Although now that I look at it, while dri-devel seems to be abused somewhat ie dri-user type questions are posted to dri-devel. The number of posts seem to indicate that more driver development (talk) is being done. Bottom line: If someone asks about the website they need to ask on dri devel in a normal posting to it. Liam ---- it depends |
From: Jens O. <je...@tu...> - 2002-05-14 22:29:04
|
Ian Molton wrote: > > Hi. > > It has come to my attention that the DRI website is, well, lacking. > > I'd like to offer my services in bringing it up to a nicer standard. > > Who should I be working with on this? Frank Worsley has done an excellent job with our site...you should have seen it before :-) However, Frank's time with DRI stuff appears to be more limited over the last few months. Perhaps you can give us some detail of how you would propose "improving" our site. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Frank W. <fwo...@sh...> - 2002-05-15 04:56:13
|
Hi Jens, Ian and all ... I don't really care what anybody wants to do with the site. I don't have time (or much interest to be honest) to do anything more with it, other than to maintain it. So, if Ian wants to overhaul the whole thing, then he should go nuts. I've received emails from several other people promising to do the same, but then nothing came from it. It's going to be interesting to see if Ian will get it done. Basically, anyone can do whatever they want - but don't expect any help from me. :) - Frank P.S.: somebody else sent in this mockup for a new site, I guess you could use it for inspiration (not sure if the link still works): http://www.littledragon.f2s.com/pre/dri/ |
From: Jan S. <th...@bi...> - 2002-05-15 13:45:58
|
<quote who="Frank Worsley"> > Hi Jens, Ian and all ... > *snip* > > P.S.: somebody else sent in this mockup for a new site, I guess you > could use it for inspiration (not sure if the link still works): > http://www.littledragon.f2s.com/pre/dri/ > www.littledragon.f2s.com seems to have been around in February, but I can't reach it now. J. -- Jan Schmidt th...@ma... ENOSIG |
From: Ian M. <sp...@ar...> - 2002-05-15 20:32:08
|
On Wed, 15 May 2002 23:45:46 +1000 Jan Schmidt <th...@bi...> wrote: Doh! try again... (sorry Jan, didnt mean to choke up your mailbox! :) > www.littledragon.f2s.com seems to have been around in February, but > I can't reach it now. Well, I've completed the basic design and layout of the new site (basically a tidying and reordering of the original), and aside from a few graphical cleanups, Its ready for new bits to be added. Here are some things I think should be worked on: 1) I *NEED* info about what cards have what features supported by DRI, like the radeon driver does already. 2) Can someone rehash the voodoo5 glide compilation guide to be a generic voodoo guide please? I KNOW its a very trivial difference to the configure line, but I no longer have a voodoo3 and so dont know the change. 3) Can people help me compile a list of janitorial tasks that could be undertaken by new developers? perhaps installation cleanups, or trivial driver tidyups ? 4) Can people who have information about the intimate details of card HARDWARE (eg. register locations, DMA engines, etc.) please send me them, so that I can add them to the developer documents? 5) Can someone with a nice package re-draw the DRI flowcharts? the Precision Insight ones look like Fischer Price 'my first flowchart'... 6) What is required in order to produce drivers for other architectures - If people tell me this, I will add it to the 'help us' section of the site. Perhaps someone could set up a mailbox that people wanting support for other architectures could send messages to, so that demand can be guaged. So, lets get to it :) |
From: F. <j_r...@ya...> - 2002-05-15 21:45:02
|
Ian, On 2002.05.15 21:39 Ian Molton wrote: > ... > > Here are some things I think should be worked on: > > 1) I *NEED* info about what cards have what features supported by DRI, > like the radeon driver does already. I think that more important than raw data is to establish a easily parsable format for that (either XML, or plain comma-seperated-values) and a template for the property sheet so that it can be easily maintained. Once this is done is just a matter of giving it to the devlopers or issuing a RFC for each card to everyone fill in the holes. > 2) Can someone rehash the voodoo5 glide compilation guide to be a > generic voodoo guide please? I KNOW its a very trivial difference to the > configure line, but I no longer have a voodoo3 and so dont know the > change. > > 3) Can people help me compile a list of janitorial tasks that could be > undertaken by new developers? perhaps installation cleanups, or trivial > driver tidyups ? I don't think that we should frustrate the potential new developers expecations with janitorial tasks. I'm of the opinion that if one can code then one should do it. The janitorial tasks should be taken by users that want to aliviate the developers load so that they code more. I think that the two most rewarding things that a potential developer can do is enhance the documentation and/or bugfixing. Both these tasks contribute to quickly generate the required know-how to start working on missing features. They give you better understanding of the architecture and the code. I can be more specific: * Documentation: - update the existing documents - change the code comments to Doxygen so that we can automatically generate reference manuals of the subsystems and the drivers. - add more items to the Developers' FAQ * Bugfixing: - Basically pick a bug on the card of one's choice and hunt it down! > 4) Can people who have information about the intimate details of card > HARDWARE (eg. register locations, DMA engines, etc.) please send me > them, so that I can add them to the developer documents? Mike Harris posted recentely a link with this information for 3DFX, but this a rare exception. Most of the documents that the current developers have are under NDA (see http://dri.sourceforge.net/doc/faq/getting-started.html#NDA). > > 5) Can someone with a nice package re-draw the DRI flowcharts? the > Precision Insight ones look like Fischer Price 'my first flowchart'... > I kinda link their style... ;p > 6) What is required in order to produce drivers for other architectures > - If people tell me this, I will add it to the 'help us' section of the > site. Perhaps someone could set up a mailbox that people wanting > support for other architectures could send messages to, so that demand > can be guaged. > > So, lets get to it :) > Good luck, José Fonseca |
From: F. <j_r...@ya...> - 2002-05-16 08:47:54
Attachments:
docs.txt
|
On 2002.05.15 23:17 Ian Molton wrote: > On Wed, 15 May 2002 22:42:25 +0100 > José Fonseca <j_r...@ya...> wrote: > > > Ian, > > > > On 2002.05.15 21:39 Ian Molton wrote: > > > ... > > > > > > Here are some things I think should be worked on: > > > > > > 1) I *NEED* info about what cards have what features supported by > > > DRI, like the radeon driver does already. > > > > I think that more important than raw data is to establish a easily > > parsable format for that (either XML, or plain comma-seperated-values) > > and a template for the property sheet so that it can be easily > > maintained. > > I agree. I just want the values for the 'first pass'. Do you know if the > server is running any database or such? > > What facilities do I have with which to play? Take a look to SF documents (http://sourceforge.net/docman/?group_id=1), section 7, especially the http://sourceforge.net/docman/display_doc.php?docid=4297&group_id=1 . You'll probably want to reuse much of the stuff thats is in the site. I don't know in what scripting language that is. > > > 3) Can people help me compile a list of janitorial tasks that could > > > be undertaken by new developers? perhaps installation cleanups, or > > > trivial driver tidyups ? > > > > I don't think that we should frustrate the potential new developers > > expecations with janitorial tasks. > > I wasnt suggesting that we foist jan. tasks on them specifically, but I > do know that having a big selection of tasks will encourage a broader > range of newbies. Plus it gives a stepping up point for the lesser > skilled programmers oiut there. > > > I'm of the opinion that if one can code then one should do it. The > > janitorial tasks should be taken by users that want to aliviate the > > developers load so that they code more. > > Well, lets present all our little tasks, so people can pick and choose. > > > I think that the two most rewarding things that a potential developer > > can do is enhance the documentation and/or bugfixing. Both these tasks > > contribute to quickly generate the required know-how to start working > > on missing features. They give you better understanding of the > > architecture and the code. > > Definately. > > > I can be more specific: > > * Documentation: > > - update the existing documents > > - change the code comments to Doxygen so that we can automatically > > - generate reference manuals of the subsystems and the drivers. > > - add more items to the Developers' FAQ > > * Bugfixing: > > - Basically pick a bug on the card of one's choice and hunt it > > down! > > Or, pick an unimplemented feature and let rip :) All the more reason to > need feature lists. > > > > 4) Can people who have information about the intimate details of > > > card HARDWARE (eg. register locations, DMA engines, etc.) please > > > send me them, so that I can add them to the developer documents? > > > > Mike Harris posted recentely a link with this information for 3DFX, > > but this a rare exception. Most of the documents that the current > > developers have are under NDA (see > > http://dri.sourceforge.net/doc/faq/getting-started.html#NDA). > > Indeed I shall. > > > > 5) Can someone with a nice package re-draw the DRI flowcharts? the > > > Precision Insight ones look like Fischer Price 'my first > > > flowchart'... > > > > I kinda link their style... ;p > > perhaps they are OK for a conference, but I think they need prettying > for normal developers. They /dont/ show layering clearly. > Well, even more important, there are slightly outdated too. Jens posted an avaliation of the documentation state some months ago. I attached my local copy (which is meant to include it the FAQ references eventually). "dia" and/or "sodipodi" are two nice applications for this. (I'm a gnome desktop user). > > > So, lets get to it :) > > > Good luck, > > Yep. > José Fonseca |
From: <si...@hi...> - 2002-05-16 02:04:22
|
On Wed, May 15, 2002 at 10:42:25PM +0100, Jos=E9 Fonseca wrote: > I don't think that we should frustrate the potential new developers=20 > expecations with janitorial tasks. >=20 > I'm of the opinion that if one can code then one should do it. The=20 > janitorial tasks should be taken by users that want to aliviate the=20 > developers load so that they code more. >=20 > I think that the two most rewarding things that a potential developer can= =20 > do is enhance the documentation and/or bugfixing. Both these tasks=20 > contribute to quickly generate the required know-how to start working on= =20 > missing features. They give you better understanding of the architecture= =20 > and the code. >=20 > I can be more specific: > * Documentation: > - update the existing documents > - change the code comments to Doxygen so that we can automatically=20 > generate reference manuals of the subsystems and the drivers. > - add more items to the Developers' FAQ > * Bugfixing: > - Basically pick a bug on the card of one's choice and hunt it down!= =20 Actually, if there was a list of janitorial tasks somewhere, it'd provide a very convenient point to start working on the code . . . There's a /lot/ of code in the DRI system, and a lot of it is very hard for a newcomer to follow (the cpp generated function names in large parts of the drm code, for example - "why doesn't grep show this function that turned up in the debug output??"). Janitorial stuff, or any basic code cleanup, would give people something simple enough to wrap their hands around, but not so complex/deep that they /have/ to understand all the code before they can do anything.=20 Documentation fixes, by the way, /are/ janitorial stuff, unless they're changes to reflect major reworking of the interfaces. And, particularly at this stage, bugfixing /isn't/ - you need something way beyond a newcomer's understanding of the code to fix the kind of bugs that turn up in the tcl branch, for example.=20 I think just having a list of things that a newcomer could look at, work on, and quite reasonably expect to have patches accepted, would be an excellent thing. Nothing will get people involved more quickly than having their patches, however trivial, in the code. Simon --=20 PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS)=20 My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/=20 |
From: Ian M. <sp...@ar...> - 2002-05-16 02:11:08
|
On Thu, 16 May 2002 12:04:18 +1000 si...@hi... (Simon Fowler) wrote: > I think just having a list of things that a newcomer could look at, > work on, and quite reasonably expect to have patches accepted, would > be an excellent thing. Nothing will get people involved more quickly > than having their patches, however trivial, in the code. Thats the idea... so... anyone got a list of tasks? Also, what services are available to me on the webserver? do I have mysql ? |