asterisk 1.2.0-0beta1

[Jose Carlos Garcia Sogo]

El dom, 02-10-2005 a las 13:22 +0100, Mark Purcell escribió:
> Tzafrir,
> 
> Thanks for the commit work.  I guess we will go through some growing pains as 
> we move to more shared working.

  Wooops! Of course, thanks Tzafir for your work. No criticism involved
in my previous mail. I was only pointing out some problematic stuff.

> 
> Note the zaptel-1.2.0-beta still is not really in a releasable/ working shape 
> yet either.
> 
> On Sunday 02 October 2005 12:50, Tzafrir Cohen wrote:
> > On Sun, Oct 02, 2005 at 09:47:28AM +0200, Jose Carlos Garcia Sogo wrote:
> > > El dom, 02-10-2005 a las 03:21 +0300, Tzafrir Cohen escribió:
> > > > I just commited to the svn initial Asterisk 1.2 debian/ dir. It
> > > > generally seems to work, but still needs some work.
> > >
> > >   OK, only some problems with this commit
> > >    1. If it is targeted to experimental, it should have gone to
> > > branches/scud, instead of trunk, to allow newer uploads to unstable
> >
> > OK. Somehow that point have escaped me when reading the README.
> 
> The README for pkg-voip does state that experimental development will be made 
> in trunk/ and that if an new unstable package is needed it can occur through 
> copying from tag/. I have come across a similar issue with pkg-kde-extras, 
> where I copied the README from pkg-voip.
> 
> Happy to work with either system, in the asterisk case a branch makes sense as 
> there appears to be potential differences between the packaging for the two?
> Where is the branches/scud option documented, if anywhere?

  No it isn't, and README file should be updated. It was written when we
were developing in experimental, with a "stable" version in Sid, which
we were expecting to propagate to testing.

> > >   Which means that when we want to upload released 1.2.0, we will have
> > > to use another trick or mak epoch 2: For example, something as easy as
> > > 1:1.2.0.beta1.dfsg-1 will work (as final will be 1:1.2.0.dfsg-1 and d >
> > > b) Anyway, dpkg --compare-versions is your friend in this situations.
> >
> > I didn't like it either. But I saw it used in the libpri package. What
> > would you suggest? Also considering that the original tarball will
> > differ from beta1 to final.
> 
> The commit/ and upload of libpri was a mistake on my behalf :-( as has been 
> pointed out they aren't lower :-(  We can finesse the libpri & zaptel 
> numbering mistake when the release version 1.2.0 is uploaded to unstable as 
> there is no checking that packages uploaded to unstable > experimental.
> 
> I have just committed the asterisk changelog to trunk) with the 
> 1:1.2.0.beta1.dfsg-1 numbering as that seems best and most sensible.
> 
> The .orig.tar.gz will actually be two different uploads as 
> 1:1.2.0.beta1.dfsg-1 & 1:1.2.0.dfsg-1 will be considered as two different 
> upstream packages and each will require it's own .orig.tar.gz.

  Yes, this is the way. If not we should include final release like a
patch.

> 
> > >   I was going to fix this a bit, but first I need to know if this
> > > release is intended for experimental or not.
> 
> Yes this should go into experimental. As a rule of thumb I like to keep cvs 
> and non-released versions to experimental provided there are relatively 
> mature released versions in unstable.

  Ok, I supposed that, but I do not follow very close asterisk
development.

> 
> > Very. I would have given it more polishing if I had not suspected this
> > would mean yet another week of delay.
> 
> This is what svn is for, so that we can all do a bit at a time. At least we 
> have a 1.2.0.beta commit we can start working on together. Once we are happy 
> then we can tag/ release. So please polish away!!

  Of course, that's what SVN is for. And if someone makes and error in a
commit, it can easily reverted or fixed.

  Thanks
-- 
Jose Carlos Garcia Sogo
   jsogo at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20051002/d361d208/attachment.pgp