On Fri, Apr 2, 2010 at 2:02 PM, Todd Hodgen <[email protected]> wrote: > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of M. Ranganathan > Sent: Friday, April 02, 2010 10:38 AM > To: Eric Varsanyi > Cc: sipX developers > Subject: Re: [sipX-dev] Sustainable open source -- suggestions solicited. > > On Fri, Apr 2, 2010 at 12:18 PM, Eric Varsanyi <[email protected]> wrote: >> >>> Questions I have for the developer community : >>> >>> 1. Development environment : EDE has helped a great deal in lowering >>> the barrier for participation. Kudos to Paul for that. Is this enough. >> >> EDE is great to bootstrap to a working setup. My biggest issue with it is > the multi-hour wait between each 'cycle' when there's a problem and its non > iterative nature. I've hacked the build script (violently) to keep it from > rebuilding all the dependencies after a simple compile error almost every > time I've used it (5 or 6 times). >> >> I had to build something like this for new developers on our commercial > product. A pattern that seems to work well with completely virgin (to a > codebase) developers and is still useful to veterans is a helper tool that > knows all the subtle dependencies needed to make a build work and then make > a running development environment (just like EDE). It helps set up the > environment (creating a file with env vars needed, creating dirs, etc) but > then also reports on dependency or other environmental issues rather than > just starting from scratch each time. Each aspect of the setup should be > runnable individually (ie: "build me an eclipse config, everything else is > fine", or "remake the env-ede file", or "check that I have all the needed > deps to run a build and tell me what's broken") as well as in a single 'do > it all' step. This tool ends up being rather useful in the build section of > an RPM as well. >> >> I still don't understand the difference between a 'designer' build and a > normal checkout/make build other than the designer build pushes to a local > install tree and normal build pushes to /usr/local (and a 'normal' build > doesn't run for me since December). >> >> Making incremental changes and testing them is very painful, it should be > possible to 'make' and run from the same tree w/o installing and a normal' > make' should only really build the one .o that changed (for C/C++ projects) > and relink. Likewise for Java stuff you should be able to make/ant/mvn, get > the jar or other artifacts generated then just restart the daemon w/o a > lengthy install/deployment step. > > > You can go to the particular build directory and from there run > configure ( your cwd has to be in that directory) then make all > install > > for example, from BUILD/sipXbridge > > rm Makefile > > ../../sipXbridge/configure > > make all install > > You do not need to make all install every time from the root of the build > tree. > > > You can also run autoreconf in the particular src directory you want > to reconfigure. > > for example cd sipXbridge > > autoreconf -if > > Make sure you delete the old Makefile.in > > I agree I had to find out by experimentation (this should not be > necessary). I'll update wiki. > > > > > Many in the user community, or implementation community might be more > accurate, are simply not programmers, unless you count writing in quick > basic or early visual basic as being acceptable. That is not to say I for > one don't have an interest in development. I believe a post last week that > talked about building some funding options for development of features might > be a great solution. > > As an example, if a pot was out there to develop a feature for a few > thousand bucks, there may be developers that would be interested in doing > the work. > > I'd propose one pot for now - a pot to pay a developer to create the > documentation and the processes to overcome the shortcomings that keep > developers from getting involved. Maybe that is paying some of the people
No pot necessary ( not even the smoke-able kind ) as far as I am concerned. > who have left the team recently to sit down and create a detailed document > to assist new developers. > > Baby steps are always good, and might be a great way to start reshaping the > project as a whole. > > Simply looking at the number of emails on the dev list demonstrates that > things are changing........................ > > You should not need to be part of the priesthood to develop code for sipx. It is not rocket science. sipx is a complex project and requires extensive domain knowledge; however some examples and HOW to docs would help. I'd like to throw in an examples project in the distribution. Some ideas (please chime in if you have others): A simple user agent that gets visited in the signaling path ( all the business about redirector plugins that I am finding out about ). A simple back to back user agent that stays in the signaling path (and does nothing but forward signaling). A simple redirector plugin. A simple auth plugin. A simple gateway that proxies requests to the wide blue yonder. SipXconfig -- there is a lot to document there. I cannot even begin to outline the work. There is a lot more that can be done. I would like to work on a set of "core API for developers" that allows people to write extensions. I wish we could have an "openfire like" plugin architecture for sipx so extensions can be easily developed and deployed along with config pages for these extensions. Between releases is a good time to start working on these things. Regards, Ranga -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
