Hi Zearin/Tony, Welcome! You've already started contributing by a) being an enthusiastic user and b) providing requirements. Given your skill set, one of the best things you can do is keep track of things that confuse you and document them in our developer's Cookbook (which is written in Docbook XML) as you go along.
On Nov 21, 2007 7:31 PM, Tony Rogers <[EMAIL PROTECTED]> wrote: > What is the difference between /src and /src_new ? That was one of my favorites when I joined. The ./src_new tree is the old source tree. It's gradually (and I do mean *gradually*) being migrated to the new ./src tree. Makes sense, right? :-) > I am using Eclipse (EasyEclipse for LAMP distro, based on Eclipse build id > #: M20070212-1330). I've noticed the Maven file, but I only have a passing > familiarity with Maven. Do I need to use it? Do I screw anything up if I > don't use it? We don't use Maven. There's been some work to migrate to it, but our standard build uses Ant. If you're using Eclipse, things should build out of the box there as well. Although Ant is the "official" build environment, all the core developers use Eclipse. If you're using Eclipse, you should be able to use our Eclipse Project Set Files to checkout and setup all the related projects that you need. It will configure the projects using the same settings that all the core developers use. > What's the standard workflow for working on open source? Pretty much the same as any other project. > In other words, is it something like the following? [...] That's pretty close. Those who believe in Test Driven Development (TDD) would insert a step of writing a (failing) test before the coding step. When the test passes you know you're done. (In theory. The practice tends to be less black & white since bug free tests aren't any easier to write than bug free application code.) The last step before committing should always be a clean unit test run using the Ant build procedure (build/build2 clean,tests). Breaking the build (ie it doesn't compile) is the worst thing you can do, but causing tests to fail is almost as bad. Occasionally the test is wrong and needs to be fixed, but usually there's a problem with your change. > Is there any work particularly suited for total OSS n00bs? :) Documentation and testing are great tasks for newcomers. Our bug tracking system is groaning under the weight of bugs from the ages. Helping triage/confirm/verify bugs and fixes would be a help. If you want to encourage development of an XSD code generator, writing a good set of requirements or description of what it should do would be a great start. What UML elements should map to what Schema elements? etc, etc. We have several code generators already (Java, C++, PHP, etc). The traditional way of creating a new one is to clone the Java code generator, but it was never a great starting point and now we've got many copies of the same crappy code. Consolidating them into a core templating engine and a set of language specific templates would be a great boon to future code generator creators, but is probably too big a task for you to tackle until you get more experience. The C++ code generator (it's in a separate module and Tigris project) might be a good place to start to see what a code generator looks like. It's probably the one that's had the most recent effort applied to it. Welcome aboard! It's always great to have new contributors. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
