John,

Thanks for helping us understand how you use it and what's important to you.

The ISO stuff is Darrick's domain, so I'll let him tackle that.

I just banged out some directions on burning images and uploading build results 
to a running system.

As for the move to 1.8: yeah, I think everyone is on the same page.

-Philip


On 8/22/10 7:21 AM, John Novack wrote:
> 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].

Reply via email to