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.
> 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.
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.
> This is by no means an easy thing to do. I've always had a huge
> problem dealing with other people's code. This isn't a comment about
> their code but about various things about me that make it hard for me
> to glean the "big picture" from what they did, as well as resistance
> to other people's way of doing things. The other day, I was working
> on something for Howard, adding a feature to some of his code. When I
> first looked at it, I though, "This isn't how I would structure it at
> all!" So I started trying to rewrite it in a way that made the new
> feature fit in cleanly. Of course, I was going to do lots of
> copy/paste of useful stuff that was already there, right? In the
> process, I (a) ended up copying almost everything anyhow, and (b)
> finally had it dawn on me the big picture of what he was doing. At
> that point, his original code made perfect sense, and it became
> obvious as to how to add the new feature. This general attitude is a
> major flaw in me as an engineer.
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.
> > 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.
> 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.
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)
