On 10/20/06, Vinicius Santos <[EMAIL PROTECTED]> wrote:
I believe people should start by submitting patches/files(or link to them) to the list, and after a period of "test" receive write acess if requested. That's how it works on most projects with centralized version control.
Sure. And on top of that, we can simply let in people who we know. If someone's been a member for a while and seems halfway sensible, then they should just ask, and we can give them access.
Maybe it's a little too early to think about that, but how are diverging direction with regards to software development be dealed with? Lot's of "subprojects" in the tree? What are going to be the parameter for projects to go into the tree?(Think about con kovilas realtime patch, or Reiser4 filesystem).
Definitely not too early, because it's happened already. It's not always appropriate, but for the most part, I would like to see convergence of related projects. For instance, Nicholas and Simon (who should be given write access if they don't have it already) have done a great job with their respective video test blocks. But I would PREFER to see them converge to a single library, with no redundancy. 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. 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.
Asking mostly how the "peer revision" system would work, because it might get unmanageable or confusing to new comers.
Convergence should be our general strategy. That doesn't mean people can't contribute wholly new ideas. You can't converge two totally different ways of characterising a problem (e.g. state machine in Verilog like our memory controller vs. von Neumann programmable like our video controller). But we should strive to have a "main" version of something that adopts good ideas from other contributions. Meanwhile, we can have "auxiliary" projects that likewise adopt from related projects, and at some point, we may choose to redefine who is "main". 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
