Wim Godden <[EMAIL PROTECTED]> writes: > 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. > How is FreeVSD > structured ? Which file has which purpose ? Not a single of those questions is >answered > in the documentation. Fair enough. But it is unlikely that these will ever be answered. VSD consists of three sets of tools: the protocol implementation (vsd), system utilitites (sys-utils) and userland virtual server utilities (userutil). There is also a support library (libvsd) used by the tools. The protocol is implemented by modules (mod_*) within vsd. Why not just scan around the source code, (use grep), searching for keywords related to the area that you are interested in improving. Each source file contains a one-line summary of the code contained therein. > 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. > So suppose I request 10 things. 5 of those are needed by 80% of FreeVSD users and 5 >of > those are needed by 10% of FreeVSD users. The 5 needed by 80% will be implemented in, > let's say, about 6-12 months. The other 5 won't be implemented at all. That is not a correct assumption. If the 5 needed by 10% are ten-line fixes, then I reckon there is a much higher chance of them been implemented sooner than the 5 large changes required by 80% of users. > If I knew how FreeVSD worked, I'd implement all 10 of them and submit my code to GPL. > That way, everyone's happy : other people are happy because they get more features >and > I'm happy because I get my features PLUS I get comments on my code, which will result > in code improvements. Additionally, other people will come up with new ideas, based >on > my implementations, and this will again result in new code. > > I hope this clarifies what I mean : if you want to get more programmers working on a > project, you need to make sure the code is not only GPL, but it's easy to learn how >the > project works. If you don't do that, you'll just get tons of requests, but no code. >And > you're missing out on a great opportunity to make the project grow. 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. Nick. ------------------------- 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 -----------------------------------------------------------------------------
