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.
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.
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
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers