[asterisk-dev] SIP TCP/TLS, release policy and more (personal opinions included)

[Johansson Olle E]

>  This is something that I
> would think that the Asterisk Advisory Council (if rekindled?) would
> have a key role in with John Todd at his new role with Digium playing
> liaison between the needs/wants of the community and the needs/wants  
> of
> Digium.
Amen to that. John has already been doing a lot of good groundwork in  
the
conflict between me and the rest of the team here, so I have a lot of
hopes in him.

>
>> In order to fix that mistake, I think we have to relax and review the
>> policys and focus on delivering good and working code. We also
>> propably need to integrate large new additions and changes in a
>> managed test-this-branch branch for testing before committing to
>> trunk, since trunk so quickly moves to release. That small new
>> additions that doesn't touch core functionality, like new apps or
>> functions, move quickly in trunk doesn't really hurt. But large
>> changes to existing code should propably have a trunk-trunk for
>> testing longer than we have done recently. As always, there's the old
>> issue with getting people to test a development tree. It worked well
>> with test-this-branch, but required a lot of interaction on every
>> mailing list, and quick feed-back. Mostly a non-coding issue and more
>> of a community management issue.
>>
>>
>  Doesn't the current svn structure with a group/team branch formed off
> of the existing /trunk already provide good infrastructure for
> accomplishing what you're proposing above? I do completely agree with
> your suggested approach. We cannot put trunk into a position where  
> we'd
> be locking out the possible transition of other features/ 
> functionalities
> that are ready from trunk to release branch because SIP work is taking
> longer.

Well, there's no real community testing in the branches, so a  
coordinated effort
like test-this-branch would propably work better, but requires a lot  
of time and
work. Obviously, the release candidates did not help much either. I  
don't really
have a solution here, but we have to separate large changes from
new small cool sexy features.

I also realize that not doing 1.6.1 now, as already put in motion,  
won't happen.
A code-freeze on chan_sip would really help while we're trying to  
stabilize
it - both the trunk, the 1.6.1 (with mine and Steve's large changes)  
and 1.6.0.

>
>
>> For many of my customers, the way the 1.6 release series is handled
>> means that it's a random hit-and-miss if we can find a version in the
>> 1.6.x series that will work. Approval and testing of a product  
>> version
>> takes a lot of time and costs money. Since every 1.6.x version will
>> include new features and fixes to broken new features won't be
>> backported to the previous release, it will be very hard to put a
>> 1.6.x based Asterisk in production. (yes, I know that I missed this
>> discussion last fall, but I was off line at the time). If this policy
>> remains, someone will have to create a Centos-like Asterisk
>> distribution based on 1.6 and backport fixes and keep core changes  
>> out
>> of the code base, "Carrier class Asterisk" :-)
>>
>>
> Why does it have to be "someone" ?   Why couldn't this be a community
> oriented effort and not a fork? I think it's an excellent suggestion.
> Your points are valid. The release policy as it exists now shouldn't  
> be
> written in stone. I think it's very healthy for the community to  
> revisit
> at least every 6-12 months processes and policies to make sure they  
> are
> really "best practice" for achieving the highest level of  
> productivity.

There's a reason I wrote about it on the mailing list. I still believe  
in
the community. The question is really how much influence we have
on the project today. While I am very happy and proud that Digium
funds so much work on Asterisk, I also see side-effects that I don't
like. I have no idea on how to solve that. I do want their money
to fund work, I don't like Asterisk being turned into an in-house
project. It's not there yet, but there are alarming indications. I raise
an early warning so that we can turn things around in time.

Every effort I have done of discussing this release policy has been  
met by
"you're too late, we won't listen to you" attitude. I strongly wish
that the project realize the mistake and changes policy again.
If that won't happen, it's a must to do proper mangement of a boring  
1.6 version
in a branch in svn or elsewhere for the users that will require it,  
regardless what Digium
says. Due to trademark issues, we might have to find another name than  
Asterisk
for this version, since it will be different from the "official 1.6  
release".

/O

>
>
>> In order for this fork not to happen, we have to separate large
>> changes to current code and decide that those requires a new version,
>> like 1.8. Small cool additions that doesn't touch core or change
>> existing modules can move more quickly into release like the current
>> policy for 1.6. Apart from the SIP channel we have some very large
>> changes under discussion and implementation - IPv6 support, the new
>> bridging system, the codec negotiation framework and others,  
>> including
>> the ideas about PineMango and the security frameworks. Let's find a
>> way to implement these in a responsible way that works with the user
>> base, both the persons looking for cool new features and those that
>> want code that can be put into carrier production. I don't like to  
>> see
>> these major changes in the 1.6 tree at all.
>>
>> Sorry for the long mail, but I feel these are important issues for  
>> the
>> project. As you see, they're very important to me.
>>
>>
>
> They're very important issues to all of us. Again, you've raised very
> valid points. The community should discuss this further and come up  
> with
> a suitable go forward plan that everyone or at least the majority
> decides is the appropriate direction.  While all of this is fine and
> good, beyond the establishment of that new policy / procedure, we  
> still
> grapple with the challenge of allocating adequate resources that would
> be required to drive/support any new initiatives.