[asterisk-dev] Unstable releases lately

[Bob]

The changes window would be a good thing.

I started this thread because Tzafrir found it in the goodness of his heart
to let my support staff know that zaptel 1.4.8 was going to break my stuff.
Other than that, the only indication that I had was to see the 1.4.8 tag
being made. Anyone who develops kernel code knows that there is a loooong
time to fix their stuff when the kernel API changes. It changes without
notice (pretty much), but there is an eternity to fix drivers. With Asterisk
and Zaptel, I have no chance to pull back the release or test it.

What we do in our release process is to make an SVN commit with the word
TEST in the comment. Subversion makes an rxxx tag automagically. The test
department works out of the latest rxxx tag until there is a release.
Development continues in the branches and tags until the rxxx TEST tag gets
merged back in. Subversion is cool that way.

We suggest the rxxx tags to customers who we think that could benefit from
it. Hell, I edit files on customer's computers if I think it will help them.
What we do not do is ask anyone to be on the bleeding edge of code that we
develop. We definitely have safe releases and "try them at your own risk"
releases. 

Asterisk and Zaptel just don't seem to be that way. 

Can I find out what conditions must be right for a release?

Can I have some advance notice?

Can they be marked as beta until some good feedback is achieved?



-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Tzafrir Cohen
Sent: Tuesday, January 15, 2008 2:43 AM
To: asterisk-dev at lists.digium.com
Subject: Re: [asterisk-dev] Unstable releases lately

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.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev