On Sun, 29 Oct 2006 11:18:35 -0400 "Timothy Miller" <[EMAIL PROTECTED]> wrote:
> On 10/29/06, Attila Kinali <[EMAIL PROTECTED]> wrote: > > IMHO every sub-project should be in the tree for anyone to see, > > so that we can prevent divergence of various sub-projects that > > do basicaly the same thing. > > Yeah. What would be nice is to assign to each project one or more > "leaders" who are responsible for maintain coherency. Is that > plausible? Yes, that's the common way. And these leaders are commonly called "maintainers" of a part of the code. There is even the possibility to have more than one maintainer for a part. It just depends on how well the people can work together. > > > The general policy should be to deal with "disagreements" via `ifdef > > > directives, `include's and such so that the end user can select the > > > features they want. > > > > Hmm.. I hope not in the verilog code, there we should have a fixed > > set of features. Otherwise we end up with a ton of slightly incompatible > > cards. > > For "OGD1 as hobbyist platform," we don't care very much. Yes but we shouldn't mix this code too much into the code that will go into the TRV10 production. Otherwise we'll end up with too much hobbyist code and very little productive code. > For "OGD1 as development platform for OGA," things must be very > carefully controlled. Be also carefull not to control too much. OSS is unlike comercial development very much dependent on the happines of each developer. If the developer is unhappy because there is too much control or control overhead, he will stop developing. But on the otherhand not enough control will lead to a hobbyist project or too long development time. It's like being caught between a rock and a hard place. > > The driver code on the other hand will not need many (other than > > to account for different OS kinds and versions) ifdefs as its > > functionality is defined by the interface it has to provide > > and by the functionality of the card. > > I think the thing to start with is a non-driver, actually. This is called "user space driver" :) > I do this > with Tech Source products when bringing them up. Use lspci to find > the device. Use libpci to get its physical address. There are system calls to get the adresses directly. Even in user space. Though i would need to look up which ones they were. > Use mmap to map > it into a user process. Do PIOs. No interrupts, of course, but this > is a good way to get first connect. It's very simple and completely > generic (it would work with any variation on OGD1 devices). > Indeed. At school, we're working on a speech recognition project, and > we just divided the work into discrete pieces that we're working on > separately. My programs' output are input to someone else's programs, > etc. We probably won't hardly look at each other's code. There is a book about this: http://www.spinellis.gr/codereading/ I stumbled over it while i browsed the english books section of a book store in Japan. I didn't read it, but a quick look at what was written didnt leave a bad impression. > (1) OGA-specific -- these things are used ONLY for OGA, so the > direction should be clear, and all changes will be percolated through > people in charge, like myself. > > (2) Completely unrelated -- hobbyist projects that will not be used in > OGA, at least not in the short term. Those projects will get > SUGGESTIONS, but no strict controls. > > (3) Components used by both -- these include things like standard > video, memory, and PCI controllers. They will be under strict > control. But if someone wants to fork one, that's cool too. > > Actually, forking is always an okay thing, although for some things, > we may request that people flesh it out really well before requesting > space on the SVN server. We especially don't want to have a lot of > forks. 2 or 3 major ones are okay. But beyond that, people will be > asked to combine their ideas with an existing fork. IMHO forks should live on a different repo. We do not want to clutter the main project with too many sub project. Maybe it would be a good idea to provide a git interface to the svn, for those people (git is simpler to fork). But let us first see how many people actualy would do a fork. Attila Kinali -- Lotus Notes ist eine verteilte Datenbankapplikation, als Sample ist eine miese Groupware dabei ;) -- Lukas Beeler _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
