On 10/29/06, Attila Kinali <[EMAIL PROTECTED]> wrote:
On Fri, 20 Oct 2006 11:36:37 -0400
"Timothy Miller" <[EMAIL PROTECTED]> wrote:
> On 10/20/06, Vinicius Santos <[EMAIL PROTECTED]> wrote:
> > What are going to be the parameter for projects to go into the tree?(Think
about
> > con kovilas realtime patch, or Reiser4 filesystem).
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?
> 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.
For "OGD1 as development platform for OGA," things must be very
carefully controlled.
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. I do this
with Tech Source products when bringing them up. Use lspci to find
the device. Use libpci to get its physical address. 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).
Nope, it's a generel flaw of engineeres who do not work in
companies with a strong peer review system (ie 99.999% of all companies)
and have never been in the OSS field. Reading and understanding
code is one of the most important abilities of any engineer
(not limited to those who write C/C++/Java/VHDL/Verilog.., but
also including those who draw schematics). But unfortunately,
there is no school that teaches it and only very few decission
makers see its value.
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.
> > Asking mostly how the "peer revision" system would work, because it might
get
> > unmanageable or confusing to new comers.
Like it works in most other OSS projects:
Disputable code or patches that change a lot of things are
first send to the mailinglist for discussion. Undisputable
changes are directly commited to svn and reviewed by those
who read the svn log mailinglist.
We'll have three kinds of projects:
(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.
> Oh, one other thing: Another job for the repository is to have
> someone actively work to maintain a sensible hierarchy. They would be
> responsible for classifying things, creating a sensible directory
> structure, and moving things around in the tree. Obviously, one
> person could do multiple jobs if they like.
Actualy, this is one of the things that should be discussed
on the ml first. Moving around files at random can be major
pain for everyone if it is done carelessly or without considering
everything that is involved.
Ok, let's see if we can have a good look at what's in there now and
see if we want to move anything around.
Thanks.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
