>> There are so many Cambridge debating society tricks in your response I >> don't know where to start :) > This is not a useful remark without support. If there are fallacies in > your interlocutor's case, name the fallacies and pair them with the > instances that occur. The burden is on you to make obvious to your > reader how your opponent is failing to make sense; if you fail to meet > that burden, you're not arguing, but throwing shade.
Yes Brandon, you're absolutely right, the ideal thing would be to dissect every argument and point out all the half-truths and omittences made. But it is so much work, and the result would be so long nobody would read it, that in this case I just resorted to flagging what I think is going on and only replied to the main points as you saw in my previous message. > I personally find the disputes over this topic difficult to follow, and > would prefer that the arguments be presented in the form of syllogisms. Yes that would be nice, but probably too much work for anyone. The next best thing is to provide a summary of the main discussion about a source package field that records what git commit id and/or git tree id the packager claims to have produced it from. I will try to write that summary later, or maybe even publish the conclusion in the form of a suggested Debian Policy update and have all the arguments for and against in that proposal. You can also get the main point about the new fields by looking at what is new in the Debian Policy version 4.7.3.0, and reading what is new in the policy is good in general anyway. The side discussion about arguments for and against deprecating the ability to track upstream pristine tarballs and detached signatures, and git tags and git tag signatures should be in a separate thread or just in their own bug reports (e.g. #1110269, #1106071, #1118381, #1118383, #1111331).
