I support a fair number with the geni-586 flavor on HP thin clients.
Some are using or have upped to 0.7.2, and no one really has a desire to
use Asterisk 1.6 for our application as a gateway to the Collectors
network. Some are using Cisco 3810's via SIP, a few with single port T1,
to mate with their electromechanical switches. Others strictly SIP
either to ATA's, 3810's or SIP phones.
Many are still using either 0.5 or not remote updatable versions of 0.6,
and since they work, best left alone. Not everyone has a replaceable CF
card.
They really love it, by the way, the web interface as it has evolved, is
really user friendly for users who are more comfortable with relays and
wires.
My suggestion would be the following, in no particular order,
understanding that they my not be much fun, but before or while moving on:
Fix the ISO to install to a disc, CF or USB. ( reported from a
potential user )
Clarify and finish instructions, and clean up scripts for those brave
souls who want to "roll their own"
Under prerequisites - ??? isn't very helpful in specifying a package!
Several pages on creation of an ISO, image , and tips and tricks don't
exist yet
Concentrate on Asterisk 1.4 and the eventual move to 1.8. 1.6.x is,
from the way I read Digium, a dead end
John Novack
Philip Prindeville wrote:
Before we move the discussion to -devel to bang out the details, why don't
we get a sense of what the users want in bold strokes?
For instance, how many people are running 1.4? How many run 1.6?
And of those running 1.4, how many were waiting for 1.8 so they could skip 1.6
as an interim release?
-Philip
On 8/22/10 12:19 AM, Darrick Hartman wrote:
Philip,
The point of a numbered branch is stability. That's why a majority of
the changes that have happened in trunk will never make it into 0.7. It
doesn't make sense to do so. Branching makes more sense when things
have been tested a bit more thoroughly. I'd have little objection to
branching trunk now into 0.8 except we don't have the resources to
maintain 0.7, 0.8 and trunk. 0.7 will be maintained for bug fixes and
security updates through the life of Asterisk 1.4. There are a few more
security updates that need to go into 0.7 after which 0.7.3 will be
released.
After we do branch, I would ask you to only work on 0.8 since we really
need to do a complete overhaul (of trunk) before releasing a different
branch after that--the toolchain is horridly out dated as you've
mentioned many times in the past. Yes that's going to be a huge effort;
an effort that we will need to plan out at some point in the future.
It's not worth making other changes to what's currently in trunk because
it will not be the basis for 0.9. 0.9 will likely be a completely new
codebase. Nothing the end-users need to worry about in the short-term
because 0.8 with Asterisk 1.8 should be maintainable for the next year
or so.
I can branch trunk to 0.8, but will not cut an official release from 0.8
until after Asterisk 1.8 is stable. I see little point in maintaining
1.4 or 1.6 support in 0.8. Go ahead and remove the other versions. We
can support those in 0.7 (unless you really want to keep them).
Why not move this discussion to the -devel list instead. It's better
targeted at that list.
Darrick
On 08/21/2010 08:02 PM, Philip Prindeville wrote:
On 8/19/10 11:34 AM, Philip Prindeville wrote:
I'm currently managing to build almost all of trunk... I think wanpipe and
ngrep are still broken.
There had been some build damage introduced into ppp/rp-pppoe where the
generated binaries were broken. Actually, it was more that the packaged
makefile's weren't cross-compilation friendly... I've submitted patches
upstream to both maintainers... and even suggested to them to roll rp-pppoe
into the ppp distribution (it forked a while ago).
PPPoE is once again working.
I'll see if I can order a PPPoA line and get PPPoA working as well.
I'm running astlinux with asterisk trunk and it seems to work fine.
I saw that some other people had been interested in running Asterisk 1.8 a week
ago or so, so I thought I'd let them know that with 4322 trunk is solid (at
least to my knowledge... I've not found any unresolved breakage).
So, I went back and did a quick back-of-an-envelope inventory of what's evolved
since March. This is far from complete.
Wanpipe has had no movement on it, because I've not been able to evoke a
response from Sangoma's head developer (so what else is new?).
Here's the inventory.
===
Things that bumped:
rp-pppoe
ppp
iptables
spandsp
pptpd
hostapd
compat-wireless
linux kernel
vim
autoconf
openssl
dahdi-linux
perl 5.10
netsnmp
Things that now build:
unixodbc
opensips
sipp
flite
ltp-testsuite
libcgicc
lcdproc
iftop
bluez
Added:
libiconv
recovery shell to startup
Added QoS support to various packages
Added Avahi/Bonjour support for p910nd printing
Added SIP security (local vs. guest contexts)
Submitted several Asterisk fixes upstream
Improved build methodology
===
The last item is more important than it seems, because it makes packages build
more reliably, and also makes it easier to do version bumps. It might also
have resolved some issues we had where packages would build (especially 3rd
party Asterisk functions and resources) but wouldn't load properly.
The flipside of the last item is that it required extensive changes to almost
all of the package makefiles... And porting those changes into the 0.7.x branch
would be too traumatic.
It would be easier just to fork the 0.8 branch from trunk (just as 0.7 had been
branched from trunk way back when).
At that time, I'd like to drop support for asterisk 1.6 and swap in asterisk 1.8 (there
aren't significant incompatibilities between the configs of the two, so if you've already
cut-over to 1.6.x then 1.8 should just "drop in"... at least it did for me).
Now that Asterisk 1.8 is in it's 3rd beta (and probably less than 5 weeks from
release), I'm thinking that sometime in that period would be a good moment to
branch... especially since trunk has been uncharacteristically stable lately.
:-)
That's developer humor.
Other projects I'll be taking up soon probably won't be as interesting for most: adding
PPPoA support to the configs, bringing up a new H/W platform called the "Geos"
(it's like the Alix boards, but has mini-PCIe instead of mini-PCI slots, and includes 2
ADSL interfaces).
Longer-term I'd like to add support for RoadWarrior on IPsec, but that mostly
involves configuration scripting changes and shouldn't be too destabilizing...
indeed it will port over into 0.8.x fairly easily.
That's the rundown.
If anyone has some low-hanging fruit that they'd really like to have, speak up
(not you Michael, I'm done with your lengthy laundry lists... :-) ).
Thanks,
-Philip
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
--
Dog is my Co-pilot
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
