Where is source for current FFADO release?

[Jonas Smedegaard]

On Wed, Oct 20, 2010 at 12:42:22PM +0200, Adrian Knoth wrote:
>On Wed, Oct 20, 2010 at 12:06:10PM +0200, Jonas Smedegaard wrote:
>> Current packaging of FFADO is versioned 2.0.1+svn1856-1 which 
>> supposedly means "Upstream officially released 2.0.1, merged with 
>> subsequent SVN rev. 1856, with our rev. one packaging."
>
>Though you're right this interpretation can been derived from the 
>version number, it's entirely wrong. ;) It's pure svn trunk 1856.

Sorry that I introduced this with a more fundamental rant on the very 
packaging style used for libffado.  That confused things:

I did not mean to say that the packaging version indicates that we use a 
tarball as basis for our packaging, just that whatever we use is 
(upstream!) based on that release.

...which might be true, now that I learn (below) that 2.0.1 indeed 
exist, just hidden (for me at least) from their front page.



>> Problem here is, that upstream apparently (based on the too broad, 
>> btw, source origin in our debian/copyright file) only released 
>> version 2.0.0.
>
>http://www.ffado.org/?q=release/2.0.1

Thanks.  Upstream crazynes then, I guess: I followed the "Download" link 
at the front page and found only http://www.ffado.org/?q=release/2.0.0

Or did I miss something obvious to others?

I recommend we use a more specific URL than http://www.ffado.org/ in 
debian/copyright as I believe that reference is supposed to lead to the 
_source_, not just to a project site.


>> So where is the 2.0.1 that our packaging is based on?
>
>Once again, it's not based on 2.0.1.
>
>The whole 2.0 branch on FFADO is a dead-end, everyone uses trunk 
>anyway, and if we weren't in freeze, I'd instantly update to HEAD, 
>because it contains important fixes. With the version we're going to 
>release, some devices won't work. It's a pity, but that's the price for 
>long release cycles.
>
>http://git.debian.org/?p=pkg-multimedia/ffado.git;a=commitdiff;h=7bfe3b6fcfcc9a59be6d89313ed57ac17ba2b4c2
>
>http://git.debian.org/?p=pkg-multimedia/ffado.git;a=commitdiff;h=1daa1105a1762193b39532c8202974b4e7e493f5
>
>
>One could argue that the proper package naming should be 2.1.0~svnXXX, 
>but that's more of a cosmetic thing. We might adapt to this proper 
>naming after the freeze, if desired.

I do understand that tarball-based releases are deemed unsuitable for 
this project.

Then I suggest to use a numbering (like now?) rooted in "latest upstream 
tarball release" - even if in fact we skip the tarball and go straight 
for HEAD.

I find that better than second-guessing what might be a future upstream 
number, as that is, well, guesswork.  If upstream decides a different 
numbering, or a different pace for its numbering, then we need to add an 
epoch which is ugly.


Oh, and I see no problem in steadily releasing what we believe is the 
proper code, and then just during deep freeze like now we release to 
experimental.

I would really appreciate if you would do that for this particular 
package, Adrian.  I don't do it myself since I feel really uncomfortable 
rolling snapshot tarballs (even though I've done it myself e.g. with the 
jamin package).  I'd be happy to help work on other parts of the 
packaging still - libffado really could use some internal cleanup of its 
rules file. :-)


  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101020/ef951b06/attachment-0001.pgp>