Daniel Swarbrick wrote: > Mike Fedyk wrote: >> Ok, you want comments. I have posted three versions of my zaptel >> configure fix patch and haven't received one comment on it in review. I >> want faster response from the developers for possible fixes. > > It's possible that few people are using zaptel hardware (or if they are, > they might not consider themselves qualified to comment at a developer > level). Don't worry, I face the same problem with chan_capi ;-)
I didn't know anything about autoconf a few days ago... Even someone applying the patch and confirming it works for them counts. Maybe I should post to the -users list. >> As for svn, keep it and use https instead of ssh for access. svn with >> https is easier to use and just as secure. svk is an option if any >> developer wants a local copy of the code to do private commits on a >> laptop while offline. > > +1 Let me elaborate by saying that svk works with regular svn servers. So it is entirely up to the developer to use svk or not. >> Also I've never liked it where there are multiple wikis. Use the trac >> wiki, it can include references to code and is more useful than a normal >> wiki because of that. > > +1. This is a software development project, so a wiki that ties into the > SCM platform is a good idea, IMHO. Other wikis are fine for > non-development-related projects. Development and user focused pages can be in the same wiki. Having a hard split between them is more cumbersome than if they are in one wiki. A lot of development docs will need to point to user docs, and vise versa. It may turn into some developer types contributing to user docs, etc. >> My general opinion is to do whatever it takes to allow people to work >> *now* and not letting "perfect" get in the way of "good enough for now". > > Maybe a code freeze is in order? Stop adding new features, and spend all > available resource on squashing the last remaining known bugs for a release. IMHO, what asterisk needed was a branch that incorporated all of the community bug fix patches that never made it into asterisk for whatever reason. opbx 1.0 should have been that branch. The sqlite, dialplan hashing, and other enhancements should have gone into the 1.1.x development version that became 1.2.x once released. As I see it the current features should be made opbx 1.2 and things like sofia sip will go into opbx 1.3.x development version to be released as 1.4.x once that shakes out. Openpbx needs to show in numbers the progress that has been made and asterisk versions should *not* be confused with opbx version numbers. For instance, when the manager interface is replaced and the cli is moved out of core, that should be opbx 2.0. Of course replace opbx with the future new name. +1 for exclamation Mike _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
