[asterisk-dev] Unstable releases lately

[John Lange]

Back at Fall Von 2007, during the BOF session the topic of having a
daily SVN snapshot available for download was raised and there seemed to
be agreement that this was a good idea.

If you make it easier to get early releases more people will do so and
hopefully more bugs will be found which might help improve stability.

Taking things one step further; it would be nice if there were binary
packages available from the main Asterisk web site that closely tracked
the releases as well. Maybe even an SVN snapshot binary as well.

I realize that Asterisk has always been a "compile from source"
community but the rest of the Linux world no longer is so it might be
time to have a look at this as a way of improving things for
administrators.

Just to elaborate a little; at the moment, once we build and deploy an
Asterisk box in the field using SUSE (SLES10), it would be nice if the
box would pick up the critical Asterisk updates just like it does with
all the other packages.

This should be as simple as pointing an update source to a Digium
repository.

Or is that what Business Edition is all about?

John


On Tue, 2008-01-15 at 11:42 +0200, Tzafrir Cohen wrote:
> On Mon, Jan 14, 2008 at 10:06:14PM -0700, Bob wrote:
> > >From a system integrators point of view, we are incorporating Asterisk and
> > Zaptel within 48 hours of their release. People are asking us all of the
> > time when a certain bug fix is going to be released. Since I don't make the
> > distro either, when the distro gets released, someone will ask me to install
> > it on their machine. The distro makers are the ones that spend the 24 to 48
> > hours testing their update mechanisms. They don't really test asterisk.
> > 
> > I don't think that it is that large of a task to employ some sort of beta
> > release system here. We expect that each release would be more stable than
> > the last. I should be able to grab 2 or 3 "dot" numbers back and get less
> > features for more stability, or just less features. That certainly won't be
> > the case when the little bugs that have popped up recently are fixed. If the
> > maintainers of the project can push a testing release, then the distros will
> > follow suit, and the end user experience should be much better.
> 
> Have you read Russel's proposed plan for 1.6? It seems much more in line
> with the things you propose.
> 
> 
> Also recall that most of the recent versions were released in response
> to a recently-discovered security hole. You can't start an RC period at
> that occasion.
> 
> 
> Zaptel is slightly different here. There is a common pattern where we
> rush our changes to make it to the release (and I'm also to blame here).
> This is mainly code that has been tested before commit, and we'd always
> like to get the improvements in the drivers to the customers ASAP. 
> 
> I wonder if we should try to make some "changes window" right after a
> new release. At least for changes that are not extensively tested
> in-house.