At 08:34 27/11/00 -0800, you wrote: >Jon Stevens wrote: > >> >> Somehow checking in the .jar's for Turbine has solved the low cost of entry >> problem quite nicely. Maybe you should try doing something; that is known to >> work; in your project as well to see what happens. :-) >> > >I would suggest that you consider a different "cause" to the happy "effect" that >you are observing (people find it easy to download and install Turbine). The >cause I would nominate is that you started distributing the all-in-one download >"Turbine Development Kit". (The same cause/effect happens with Cocoon now that >an all-in-one download is available).
No it started happening before TDK was available - I remember the list being inundated with newbie questions (some of them mine ;]) when jars went into CVS ;) >The only people who will observe a difference between these two approaches are >those who use direct CVS access *and* want to compile your project (as opposed to >just using it) in order to contribute to it. right. But how many download CVS but can not be considered potential developers ... >The former group does need to go to a little more effort (clearly described in >the README files in the top-level directory of the source directory). ><personal-opinion>The ability to set up a build environment succesfully, once, is >a pretty good filter for potential committer candidates :-)</personal-opinion> err - it has nothing to do with skill. It has to do with laziness. Personally I won't jump through hoops to play with a project that I may or may not end up developing with. However if all I have to do is click and compile - the project may gain an extra developer. I suspect I am not the only lazy git about ;) >I believe that it is possible to accomplish the same desired results in a >different way -- create a *source distribution* (on some reasonable schedule like >nightly) that includes all the things you might want or need. This helps the >casual developer who might be looking to get involved, without causing grief for >the experienced developer who knows what he is doing and gets royally screwed >when you include an incompatible version of a dependent project in your CVS tree. As I have said before the incompatable version would not be an issue as it is NOT put into install directory. Thus an experienced developer has no issues unless they want to compile ant tasks in main distribution that are incompatable ..... at which stage we can change jars or the developer can make use of his experience and add a .cvsignore and rm a file. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
