svn commit: r383472 - head/audio/muse

[John Marino]

On 4/7/2015 09:07, Alexey Dokuchaev wrote
> 
> No, it's not "just because", not sure why you didn't quote it: "As I've
> previously had explained, "cd ${WRKSRC} && ${INSTALL_DATA}" is two-
> command construct (vs. single, $cwd-agnostic command), 

compound cd commands are typically easier to read on logs, particularly
if it removes a loop.

> it typically gets
> longer and thus can cause line wrapping, 

Avoiding line wrapping is not a good reason

> but most importantly that it
> should not have been committed in the first place as being gratuitous
> change."

You've already gotten feedback from 3 people that they prefer the new
version, so that's hardly gratuitous.



> We do not avoid making changes merely for annotations' sake.  But we do
> if the change is gratuitous.  It also helps to maintain claner, easier
> to review diffs, and does not needlessly blow the repo size (in the long
> run it might make a difference).


The problem is that you've defined gratuitous based on if it affects
annotations in some cases.  Most of the stuff you've pushed back on, I
saw as an improvement if taken in standalone.  So you are advocating
keeping inferior structures for the sake of annotation.



> John, with all due respect, but the fact that you do not find annonation
> feature useful does not mean other people think it's useless.  Also, "svn
> blame" is not just a command some of us like while others don't, it's a
> nice and easily comprehensible reason for why we try to avoid repo churn.

I would say "if all things being equal" avoid churn with a very low
threshold.  You threshold for equal is high, thus the conflict.  This
desire to avoid change at all cost seems to be interfering with the
right thing.

There's only 3 cases:
1) the maintainer is doing it himself (not your business)
2) somebody is maintaining a ports at FreeBSD.org (I'd prefer it get
maintained rather than nothing, e.d. tkato's case)
3) somebody is committing on a maintained port that is not theirs.
(Here is where your svn blame concern has the most validity)

ports at FreeBSD.org ports are one step above deprecation.  Just let
drive-by fixers do their job on unwanted ports without giving them too
much grief.  That's my opinion.

John