[asterisk-dev] Asterisk Project Software Configuration Management Policies

[Olle E. Johansson]

13 nov 2012 kl. 16:01 skrev Matthew Jordan <mjordan at digium.com>:

> 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?

Every time I use 1.8 in labs or trainings, we get multiple crashes. The ones from last
week are reported in the bug tracker, hopefully being worked on. I'll keep reporting,
as do my customers.

Currently we have an enormous gap between the lastest release on ASterisk.org
and what a majority of the users I meet and work with use in production. I 
believe we need to close that gap and analyze why it does exist.

Asterisk is a very complex software, so new releases are buggy and cause a
lot of issues. I understand that. But being in a situation where I evaulate - on
customers behalf - a release that is many years old and port patches to releases
that are even older is not a good situation. I don't like it. Customers evaluate releases
with their configurations and report bugs that doesn't move anywhere. In the end,
they stay with what works and doesn't crash or block. And direct developers like
me to work with that version.

I think the Asterisk project really needs to find out how to try to make that gap 
more narrow. There will always be a gap, but the current situation is bad. It means
that I get no funding to port my work to trunk, since it's too far away from the original
patch and causes too much extra costs for the customer if they want me to work on it.
In the end, the patch stays at 1.4 or 1.8 level in a branch in the svn repo. I am happy
that I get the right to contribute 99% of my work to the project, but sad that so few
patches make it into the trunk.

I don't know what to say when people ask me about 11 LTS. They do believe that an LTS 
stamp is a quality assurance. It's not, it's far from, it's an indication of a committment
by the developers, nothing more and nothing less.

I can only say that it's a new release that still will be supported at the point where it gets stable
enough for production. 

My proposal was to brand a release as "LTS Candidate" to give
the customers an indication that it's a new release, we're working on stability.
But we don't recommend them to use it in production just yet. 

I understand your thoughts. It's a chicken and egg situation - will people help
us to get stability in the LTS Candidate? Maybe not.

We still have a huge gap to bridge or at least make more narrow and a communication
problem to handle. Fixing bugs is boring, but we might need to ask the community
for more help on bug maintenance and fixing, instead of just relying on Digiums
limited resources to fix issues. A bug fixing month now and then. Keep improving the
test system. <your idea here>

For a commercial company, this would have been a disaster as we would have less
revenues from software upgrades than expected... Good that we're open source and 
don't have to force our users to upgrade :-)

In the end, just keep on doing a god job.

/O