Nick Burrett wrote: > > > People will contribute to a project if they like the software > > > but would like to see a enhancement to fulfill their needs. Some will > > > make the time and take the effort to do this, while others may simply > > > put requests onto the mailing lists. > > > > Well, suppose I want to contribute to FreeVSD. Where do I begin ? > > Fine. But *what* do you want to contribute ? Or are you asking for a to-do list ? > > If you say something like, "VSD is missing feature xyz, where should I start > looking" then we can point you in the right direction.
There's a number of things I feel can be improved. I'm currently looking into high availability features, as well as load-balancing issues. One of things I'd like to implement is having a virtual server run on 2 IP's on 2 servers. Technically it's possible, but I have no clue how I'm going to integrate it in FreeVSD. > > I do want to contribute, and I'm quite capable of contributing with good code. But >if I > > have to look it all up myself, I don't think it's worth the trouble, so I'd rather > > submit my requests. > > That seems a bit unreasonable. Since you'll then complain that you don't want to > read 80Kbytes of documentation just to figure out how to contribute. Documentation > is no good without the source code as a reference, so why not just scan around > the source code in the first place. You may discover that VSD is simpler than > you think. Aha, let me reverse this. Source code is no good without documentation added to it. Everyone who has ever worked in a large software company knows that there's no life without documentation. Every project should have at least a structure overview, so other people can easily join the project. It's not hard to make such a general overview... just take a flowchart program, draw the big blocks, connect them with lines and add descriptions. Then if you're not too tired yet, draw the smaller blocks as well. In just 2-3 hours you get a solid view of what the project looks like, which makes it very easy for new programmers to see which file contains which information and where that information is used (where it's included, where the functions are used, etc.) > Well I think that the code paths with VSD are short enough that it should be > easy for somebody to quickly learn and contribute. I might be biased here > though. Well, if were into FreeVSD from the start, it's easy. If you've been following everything, you've got no problems. But if you, like me, have tons of other work, it's damn hard to suddenly jump in and start implementing... you just don't know where to start, because you don't have the overview of the system. And I'm not happy with just understand the part that needs to be changed. If I implement a system, I want to know what impact my changes might have on other parts of the system. And the only way to know that, is to know how the whole project is built. Greetings, Wim ------------------------- The freeVSD Support List -------------------------- Subscribe: mailto:[EMAIL PROTECTED]?body=subscribe%20freevsd-support Unsubscribe: mailto:[EMAIL PROTECTED]?body=unsubscribe%20freevsd-support Archives: http://freevsd.org/support/mail-archives/freevsd-support -----------------------------------------------------------------------------
