[asterisk-dev] merge policies, supported branches, API/ABI freeze (was Re: Asterisk 1.6 Release Management Proposal)

[Gregory Nietsky]

Brian Capouch wrote:
> Luigi Rizzo wrote:
>   
>> On Sat, Oct 20, 2007 at 01:31:23PM +0200, Tzafrir Cohen wrote:
>>     
>>> Yeah, right. There is not enough testing done as-is for trunk. Who are
>>> those brave souls that will test this "broken-by-definition" branch?
>>>       
>> It is not "broken by definition", it is "probably ok but it might
>> have some rough edge". Same trunk as it is now, in fact, and if
>> committers are responsible people and treat trunk with due care,
>> it is not so crazy to run trunk.
>>     
>> I wish more people would run it and watch it, both for the sake of 
>> developers and because it would make some of my "do I smell a rat?" 
>> posts about its behavior feel less lonesome :-)
>>
>> b.
>>     
come on dude dont blame it on the rats !!!! ;)

i have no problem with this i am guilty of not running trunk and using 
1.4 as the trunk in the new proposal
i hack bits on here and there and fix any problems i find (some of which 
have been rolled into trunk and not 1.4 where
i have them) the result of this is ...

1)trunk has not been tested at all by us (will be during the week)
2)customers will be hesitant to take up a offer of this does what you 
have asked for, care to try it...,
   we have been running it fine for ... weeks and XYZ corp swears by it 
and have been using it for .. weeks.
3)the proposed 1.6 dev cycle suits me 100% as this is the way we are 
working with the 1.4 tree.
new versions will be rolled out on demand to customers after a 1 or 2 
week burn in (as is done with 1.4 currently).

asterisk is better suited to this model than the kernel as the ABI/API 
is internalised and accessed via related packages/libs.
as long as the AGI/CLI/Exten logic (ZAP to some degree as it requires 
messing with the kernel) does not change  drasticaly
the ABI/API is free to evolve at will (reqiureing prehaps a 
zaptel/libpri/libss7 upgrade).it will be imperitive that when a branch 
is released
the appropriate requirements are stipulated clearly.

there are currently 30 asterisk deployments on our "Office in a box 
distro" that are directly managed and supported by us (contractually)
these are ready and mostly willing to try new things out.these customers 
will be added to the currently shallow pool using the development tree.
please note the majority of these are running linux-2.6.23 (others need 
a reboot) we run the -rc's on all our "test boxes" and when we are happy the
-final is upto scratch we release it to customers with a email to notify 
them of changes and to schedule a reboot.