Re: fasttree: hard-coded limit on branch length precision leads to erroneous results
Hi Roland,
On Fri, Mar 27, 2015 at 11:01:29AM +0100, Roland Fehrenbacher wrote:
> C> commit 5788cecbb05a4394c3fed722c47bdba5c20432ef Author:
> C> tbooth-guest <tbooth-guest@debian.org> Date: Tue Feb 25 13:43:34
> C> 2014 +0000
>
> C> Fixed package not cleaning 100% after build.
>
> this is a perfect example why it's so important to tag package
> releases. Unfortunately, fasttree doesn't have any so far. So for
> someone unfamiliar with the package history, it's
> guesswork or tedious detective research to find out what went into a
> release version of the package.
You are right. Some maintainers in our team are a bit sloppy with
tagging. The rationale of them is that we have snapshot.debian.org.
While I do not subscribe to this opinion personally I understand their
point.
Apropos tagging: There are people in the team who said they will never
tag any of their uploads to avoid that all these tags will consume more
and more space on their harddisks. I also do not fully subscribe to
this opinion but to find some compromise I deleted "historical" tags
quite systematicly only leaving tags of major versions, somehow
"important" tags (for whatever reason) and the last three tags. To my
(possibly poor) understanding this was the best compromise to invite
people to do some tagging at all without filling up to much disk space.
So please be prepared for a mostly incomplete tagging in SVN (feel free
to criticise this but its hard to change the past.)
> Good job fasttree is a tiny package
> making things easier. Looking at the date of the last commit in
> fasttree, I assumed it must have been included in the jessie version.
> On the other hand, the biolinux1 in the version number should have made
> me more suspicious ... :)
I did an upload based upon
apt-get source fasttree
and afterwards importing your patches. I stored this in the Jessie
branch of the newly created Git repository. Cases like this are not
covered by our policy document (but should). I hope I found a solution
that is easy to understand and helpful for this case.
> C> and upload the changes as a "Team Upload", without change of
> C> maintainers (this can be done when uploading version 2.1.8 after
> C> the release).
>
> You guys know best what to do in such cases. Just go ahead with whatever
> you think is right.
So I did at least for the user visible part in the Debian pool. Feel
free to find a better solution for the Git repository - I do not
consider myself sensibly experienced with Git.
> C> In any case, many thanks for spotting this and preparing a
> C> correction so quickly !
>
> It was a simple fix and given the findings described in the blog post
> pretty important.
+1
> C> Do you think it would be possible to backport the change for
> C> Wheezy as well ?
>
> I guess so. We have already built the package for Qlustar/Wheezy, so no
> principal problem. We'd have to rebuild it with a different version
> number suitable for the backports repo, but that's done in no time.
> Just a question how the upload process to the official backport repo
> works. I'm not familiar with that.
I admit I never cared about backports and I was hoping that somebody
from the team would care for it. Unfortunately this was not (yet) the
case and I'm crossing thumbs that this will become better in the future.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: