[asterisk-dev] Asterisk Project Software Configuration Management Policies

[Matthew Jordan]

On 11/13/2012 03:47 AM, Olle E. Johansson wrote:
> 
>
> I would label them "development releases".

I tend to dislike the terms "development" or "production" when used in
connotation with a major version branch.  There are certainly systems
out there built on Asterisk that are being used by businesses in what
can only be characterized as a production environment.  People chose to
deploy them in such environments to take advantage of the fax gateway or
conference capabilities that were introduced in that version.  Labels
such as "development" imply business decisions that I don't think the
project should make.

> My question here is the LTS brand. A new release is far away from something we
> can use in production at larger sites. For 1.4, it took almost two years until it was
> production ready. 1.8 is close to getting there, but still require some more work.
> 
> Labeling a brand new release LTS is a way to encourage testing, but I would prefer
> it being "LTS candidate" for at least a year. 
> 
> I have no experience of a process to evaluate for LTS - but it should at least be
> able to pass most users dialplan tests without core dumps. Maybe an evaluation
> of the bug tracker input could be used.

I think there's a history lesson in here.

We can't do much about things that occurred between 1.4 and now.  There
are a number of decisions that - when viewed comfortably from the
present - we probably wouldn't make again.  In the past few years, there
has been a much greater focus put on stability.  That comes in multiple
forms - reducing breaking changes between major versions, making things
backwards compatible, unit testing, automated integration testing, etc.
 In general, the trend is towards making things more stable and easier
for system maintainers.

There is, of course, always room for improvement - but I expect that
upgrading from Asterisk 1.8 to Asterisk 11 is a much more stable
experience than Asterisk 1.4 to Asterisk 1.8.  So far, the issues
reported have borne that out - while there have been issues reported
against Asterisk 11, the vast majority of these have been against new
features in that version, and not against features that existed in both
versions.

So, what about an "LTS candidate"?  While the idea seems attractive, I
have a few problems with it.

1. The point of having a beta - for any release - is to work out issues
that occur in production environments.  Having an "LTS candidate" is no
different than having a beta for an entire year, and will result in the
same level of testing; that is, the same people who test a beta release
of Asterisk will be the same people who test an "LTS candidate".
Someone who chooses to not test a beta release will not test an "LTS
candidate" either.  The coverage ends up being the same, and the extra
amount of time isn't utilized effectively.

2. You referred to 'core dumps' that occur on a new LTS.  I'm unclear as
to what issues have been reported against Asterisk 11 that are not also
issues in Asterisk 1.8 (or prior releases) and that are also against
features that exist in both releases.  While there are certainly
problems, I don't think there are widespread stability problems.  The
community, of course, is working hard to address those issues.

3. As with anything, problems reported against any version of Asterisk
require the community to interact and solve.  What problems are you
experiencing in Asterisk 1.8 that prevents its deployment?

> 
> I also lack a process to handle new code that is defered to the next standard release
> after the LTS is released. Code in svn branches and the bug tracker seems to be forgotten.
> 

Russell brought up a similar point in the #asterisk-dev chat room,
namely that we should have a process for how new features move through
the process.  That's related to the SCM policies, but deserves its own
page (and is on my list to document).  Part of that should certainly
include a discussion on major architectural changes and how to sync
those up with the development cycles.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org