> 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. I very much appreciate that time and effort were put into making RPM's as a first class citizen, they make deployment and testing much much easier. It would be nice if, like traditional RPMs, you could rebuild them from their SRPM. This would make trivial changes/bugfixes much easier to test/deploy and make it simpler to share patches with others w/o requiring everyone involved to have a full dev environment working. > > 2. Is the architecture documented well enough to allow a user to add a > new service? It was a non trivial exercise for me when I got started > in this project. I think more work is needed here. Where do we fall > short? I started up a wiki page based on my experiences but that may > not be enough. I didn't know there was any architecture documentation at all. Every area I've worked in (in sipXproxy, which is relatively simple architecturally, and in sipXconfig which is not) has required code inspection (lots of grep) and, esp in sipXconfig, running under the debugger to get my bearings on how major systems and class relationships actually work. The settings system in sipXconfig is a good example: a couple of sentences on how it works and the major classes involved would have saved a lot of time casting around in the dark. There is no obvious architectural or high level design documentation and queries on the dev list on where such info might be located are usually unanswered (I took that to mean there are none). Even a doxygen style comment just on major classes describing their purpose would help a lot. With sipXconfig a 1 pager that describes which technologies are used for which broad areas and maybe some very high level UML (or other) drawing of how major systems (like the settings/group system) fit together would save tons of time and frustration. It took me longer than I'd like to admit after going through Tapestry tutorials and getting a handle on how it works to realize that Tapestry is only used for a small portion of the page generation in the phone plugins, and in fact it isn't used consistently. I get the feeling that sipXconfig grew over some time and different developers chose different technology to make parts work, that's fine and what you get in a long running project with staff turnover over the years (in my experience anyway) but one or two wiki pages that summarize the actual *current* state of the universe architecturally (and someone who believes they own keeping those pages up to date) would help a lot to get over the hump as a new developer trying to d ip ones toes in. > > 3. Core services API : I would like to put together a proposal for > open API to our core components to lower the entry barrier for > developer participation. We should probably do more along those > lines. So the question is where do we fall short? Any suggestions? I > started on a "call control API" there is a "sipxconfig rest API". I > quite like the FreeSWITCH API model. > > This is a terrific project and I am a very strong proponent of open > source but like anything else it must be sustainable and benefit all > participants. I think with #1 and #2 you've hit the main impediments right on the head. Its a big pile of code and the environment and build systems are very complex and tied to each other. Most advanced users won't even try to build it. It took me a couple of months (not at full time) to get to the point where I could check out from SVN, build, and actually run the results. Contrast this with freeswitch which you can check out, configure, make, and run in 1/2 an hour (I understand why Freeswitch is simpler, just pointing out that the time they spent 'polishing' their build/test/deploy was time well spent). There is one other thing that has in the last couple of months sort of dampened my enthusiasm to work on sipXecs, as a complete outsider coming to the project I've never discovered where the real day to day project level decisions take place. I'm assuming they are done behind closed doors at Nortel/Avaya, and that's certainly fine, but major developer events are only occasionally 'leaked' to the community as offhand remarks. Fedora puts out a weekly email newsletter with the high level status of things (code cutoff / freeze dates, slips, big news, etc). I get the feeling (though I'm sure this is an overreaction on my part) that Avaya has this commercial product and team and sees the 'community' as some sort of marketing project, but the open source side isn't really in the development loop in a meaningful way. I greatly appreciate the codebase and community support, I just think if you want external community developers working on big features and architecture level changes y ou have to somehow have a process that exposes the 'loop' for anyone to see what's going on organizationally and try to figure out how to fit in and who to talk to/collaborate with on new ideas. An example of 'no loop': I've been watching -dev and -users since October or so, a 'new voicemail system' was mentioned many times in Dec/Jan... what happened with that? Recently there was a message saying 'we're just about to cut a release, once the last few blocker bugs are closed'. I'd think a major thing like a new voicemail system would have had an announcement from the developer(s) involved -- "here it is, try it out, here's what different". The helpful/informative announcements as changes to the UI CSS went in over the last couple of months are a counter example. -Eric Varsanyi _______________________________________________ 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/
