[asterisk-dev] Unstable releases lately

[Atis Lezdins]

On 1/16/08, Michiel van Baak <michiel at vanbaak.info> wrote:
> On 12:14, Wed 16 Jan 08, Paul Hewlett wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Tzafrir Cohen wrote:
> > > On Wed, Jan 16, 2008 at 09:55:01AM +0200, Paul Hewlett wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> Tzafrir Cohen wrote:
> > >>> On Tue, Jan 15, 2008 at 10:27:51AM -0600, John Lange wrote:
> > >>>> On Tue, 2008-01-15 at 09:45 -0600, Kevin P. Fleming wrote:
> > >>> Subversion has indeed some intersting capabilities for branching and
> > >>> such. But for the purpose of "building from source" all you really need
> > >>> to know is:
> > >>>
> > >>>   svn checkout
> > >>>   svn update
> > >>>
> > >>> You messed something? You delete it, and update again. You messed
> > >>> something big? delete and checkout all over again. Or move aside and
> > >>> checkout all over again. No need to keep 10 different snapshot tarballs
> > >>> around.
> > >>>
> > >> Has anyone considered using Bazaar from Canonical ?
> > >
> > > Or git? Or mercurial? Or darcs?
> > >
> > >> It is like subversion but distributed i.e. you can do commits etc
> > >> without needing the central server. Of course you can still have a
> > >> central server....
> > >
> > > Generally distributed version control systems are even more complicated
> > > than centralized control systems such as Subversion.
> > >
> > > They have very cool features for *developers*. The ones that are not
> > > afraid of using Subversion in the first place. But as for easy of use
> > > for the simple "grab the latest copy" usage pattern - they only make
> > > life more complicated, in the worse case. For instance, there is no
> > > simple and short revision number (because there's no One Repository tht
> > > sets revision numbers at commit time for everybody).
> > >
> >
> > True - but recently the asterisk SVN server was down and with Bazaar
> > that would not necessarily be a problem - you could setup 2 central
> > Bazaar servers - lose one and you still have the other.
> > Or checkout the SVN tree into a bazaar repository on your PC and use it
> > to merge with other developers independently of the central server.
>
> If your next point is really true, there would be no problem
> at all. The svn server where the commits go in the first
> place is still up and running. It's the public svn mirror
> that's having trouble and is resyncing with the master as we
> speak. The devs with branches etc are still able to commit
> their work and share code etc.
>
> >
> > I would think that anyone who uses a VCS such as subversion etc. would
> > be a developer - users just use tarballs or rpms or whatever ?
>
> This is not true.
> A lot of users that actually report bugs run svn so they can
> checkout the latest sources once the fix for their problem
> appears in svn.
> rpms etc are most of the time a couple of releases behind,
> because the packaging etc needs to be done and tested. By
> grabbing a tarball from digium you still need to compile the
> code so in that case people can most of the time manage to
> learn 1 or 2 subversion commands. This gives them the
> benefit of running the latest fixes on a production branch.

I can only add that i run SVN on my development machine, however
production is  tarball based, but i also would like to move to SVN, as
we have some custom patches. SVN is just easier for that.

About testing - we keep few releases back from latest 1.4 branch, as
it takes few days of testing to make sure that latest version haven't
broken something. Or just waiting for specific bugfix and then jump
over few versions (like our longest jump from 1.4.9 to 1.4.14). It is
actually happening because there are things broken by one release and
are fixed only several releases later.

Anyway - i hope this discussion is kind of useless now, as there won't
be any significant change of release system in 1.4, but it's already
changed for 1.6.

I would like to see that with new release system there would come some
tests done before actually announcing release. Perfectly - it would be
automated test framework with unit tests, but that's a big job to
build that. I have created simple test framework that allows testing
for crashes with all the features our dialplan provides. That doesn't
help to prevent bugs like CDR not written or recording not made. I
have some plans in this direction, but our team currently consists of
3 people, and we also have to keep up with business requirements. I
would really like to see some action of Digium in this direction.

For now i can maybe propose that official bundling and announcing is
done like few days after tag is created. First announce it for example
on asterisk-dev that this is going to get bundled, so most active
people can test a little. I could personally try to launch our
automated tests upon new RC, to see if they can crash it.

Regards,
Atis

-- 
Atis Lezdins
VoIP Developer,
IQ Labs Inc.
atis at iq-labs.net
Skype: atis.lezdins
Cell Phone: +371 28806004
Work phone: +1 800 7502835