Re: fasttree: hard-coded limit on branch length precision leads to erroneous results
>>>>> "A" == Andreas Tille <andreas@an3as.eu> writes:
Hi Andreas,
A> Hi Roland, On Fri, Mar 27, 2015 at 11:01:29AM +0100, Roland
A> 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.
A> You are right. Some maintainers in our team are a bit sloppy
A> with tagging. The rationale of them is that we have
A> snapshot.debian.org. While I do not subscribe to this opinion
A> personally I understand their point.
A> Apropos tagging: There are people in the team who said they will
A> never tag any of their uploads to avoid that all these tags will
A> consume more and more space on their harddisks.
that's one of the many places where GIT really shines versus SVN: tags and
branches have zero cost with GIT, whereas SVN makes code copies most of
the time ...
A> I also do not fully subscribe to this opinion but to find some
A> compromise I deleted "historical" tags quite systematicly only
A> leaving tags of major versions, somehow "important" tags (for
A> whatever reason) and the last three tags. To my (possibly poor)
A> understanding this was the best compromise to invite people to do
A> some tagging at all without filling up to much disk space.
A> So please be prepared for a mostly incomplete tagging in SVN
A> (feel free to criticise this but its hard to change the past.)
Just mentioned it to make people more aware. For the new GIT converted
repos there won't be an excuse :)
>> 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 ... :)
A> I did an upload based upon
A> apt-get source fasttree
A> and afterwards importing your patches. I stored this in the
A> Jessie branch of the newly created Git repository. Cases like
A> this are not covered by our policy document (but should). I hope
A> I found a solution that is easy to understand and helpful for
A> this case.
That was just fine.
Best,
Roland
-------
http://www.q-leap.com / http://qlustar.com
--- HPC / Storage / Cloud Linux Cluster OS ---
Reply to: