I would quibble with what seems to me to be the overly harsh and single-minded assessment of
"A new developer has NO value unless he has an overview of the process, the components involved and how everything hangs together." So you must understand how photons are released during the excitation of atoms before using an optical mouse? To get personal for a moment... I'm an example of someone who has a non-development need to delve into the opensource end of SL. I'm making a machinima that demands some features that really aren't available as-is and probably won't ever become stuff you'll find on the advanced menu. The fact that SL is OpenSource is part of why I felt comfortable choosing SL as this platform, because I knew if we ran into these kinds of needs, solutions would be possible. And I share the feeling Obscuro mentions of being a little fish at this table, since I never learned C++ and becoming expert at is isn't on my priority list. But at the same time I'd defend what we're doing as valuable even if we only find bugs in the software that's coming down the pipe. Part of the 'open' in OpenSource is to invite a larger tent and make us all feel welcome. Which includes encouraging people to get up and running as quickly as possible. So I salute what Soft is trying to achieve. That said, I concur with the general point that the automation machine can become part of the problem in getting started when it goes off the rails. The develop.py script we have today is an example that has often left me stuck with no real idea of why. I know when I first set up my environment, I think the biggest hill to climb was sorting through the competing documentations, because that was when 1.20 was giving way to 1.21 and Cmake, so I was mixing up my instructions between the two. After that, it was develop.py script errors, and after that hunting down the third party libraries (because again, that meant tackling different documentation at each provider). Hope that's helpful. Vector -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Carlo Wood Sent: Friday, March 13, 2009 8:52 AM To: Soft Cc: sldev Subject: Re: [sldev] Webkit versus Second Life On Fri, Mar 13, 2009 at 08:14:28AM -0500, Soft wrote: > Watching an Apple Safari/Webkit developer intro talk, they did > something pretty cool: They demonstrated that you can fetch and build > Webkit using nothing but your mouse. They assume you have the > developer tools and subversion installed. The rest is su-and-say > enough that you can just copy and paste three lines from the browser. > One to do the svn fetch, one to build, and one to launch the built > app. That is bullshit; each pasted command can start a plethora of other commands. I could write a script that downloads, build, installs AND starts SecondLife - including all shared libraries if you wish and call it "we_are_so_cool". Then you "beat" Apple Safari/Webkit: just ONE line to paste! > We're pretty far away from that. We rely on a handful of libraries > that we can't provide on our own. We need some extra development tools > installed. We have library and artwork bundles apart from the source > bundle. We have separate steps for configuring and for building. I consider most of that a plus! Having a "black box" means less flexibility and ONLY works in a FULLY (version) controlled environment. Microsoft and Apple already (attempt to) do that (and still fail often -- except during a presentation). Linux has chosen a different path. I strongly believe that a non-black box, and flexibility is worth more than a "one click" process that either works or not (that being said, I AM author of a few auto-magic scripts like http://www.xs4all.nl/~carlo17/howto/build-nvidia-kernel and http://www.xs4all.nl/~carlo17/vvinstall2 Look at those scripts to have an idea how "cool/good" one-click installations are... Do you really want this? Nevertheless, I wrote those for end-users that otherwise would simply have nothing at all. Developers should be able to understand each step. The more steps the better. What we NEED is a HOWTO that explains every step in detail (and thus, many copy&paste lines). Most of my HOWTO's are that way, look for example at http://www.xs4all.nl/~carlo17/howto/encode.html or http://www.xs4all.nl/~carlo17/svn/index.html with many little copy&paste blocks instead of one-script-fits-all. > An awful lot of new devs get lost somewhere in the process. > > Of all the above, if we were going to focus on knocking out just one > step next, which do you think would be most valuable? Which is the > highest hurdle? A new developer has NO value unless he has an overview of the process, the components involved and how everything hangs together. New developers need to learn a lot of things. The best way to learn is by doing. Changing a whole install/compile step to a one-click won't make them any wiser and they will be of no value imho. Nevertheless-- I can answer your question ;). The answer is *precisely* what the Open Metaverse Viewer project's goal is: * Only use opensource components and to remove any non-free dependencies. Your next step should be get rid of any closed source third-party libraries/software. Then we need a webpage that outlines each step for new developers to follow, rather than one powerful script. We (OMV developers) ran into this too, so you can have a look at our first attempts to outline things that need to be done on http://omvviewer.byteme.org.uk/source.shtml (courtesy Robin Cornelius) and in more detail http://omvviewer.byteme.org.uk/git.shtml > Another cool thing they do is making sure the nightly builds are > completely stand-alone. Testing a build is as simple as unpacking a > zip file and running a file in the contents - no installers permitted, > no writing to files outside that directory. The idea is that it's > possible to keep an array of nightlies and binary chop through > versions to find regressions. Mac and Linux are pretty much at this > stage. Would this be preferable for Windows BSI nightlies? -- Carlo Wood <[email protected]> _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
