Date: Tue, 07 Apr 2015 08:18:21 +0200 From: John Marino <freebsd.contact@marino.st> To: Alexey Dokuchaev <danfe@FreeBSD.org>, Adam Weinberger <adamw@adamw.org> Cc: Sunpoet Po-Chuan Hsieh <sunpoet@FreeBSD.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r383472 - head/audio/muse Message-ID: <552376AD.7010903@marino.st> In-Reply-To: <20150407023204.GA44784@FreeBSD.org> References: <201504061859.t36IxK0v000969@svn.freebsd.org> <20150407012902.GA22994@FreeBSD.org> <91AB85D3-A8DE-491C-A2D7-4E8D7E1CDC12@adamw.org> <20150407023204.GA44784@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/7/2015 04:32, Alexey Dokuchaev wrote:
> On Mon, Apr 06, 2015 at 08:07:33PM -0600, Adam Weinberger wrote:
>> ${PORTDOCS:S,^,${WRKSRC}/,}
>
> This construct is known well enough (and used throughout the tree often
> enough) to be immediately recognizable and understood. It is nicely concise
> yet still readable: using variable substitution does not make it cryptic,
> in this particular case.
>
>> is not readable. Especially not compared to the pseudo-English statement
>> into which sunpoet expanded it:
>>
>> cd ${WRKSRC} && ${INSTALL_DATA} ${PORTDOCS}
Frankly I also prefer the new version. Just because experts can read it
and understand it doesn't make it better.
>
>> You're not getting much attention when you are choosing a different thing
>> to care about each day. Pick just one or two topics that are most
>> important to you, and work to get those behaviors fixed.
>
> What if everything is important? Frankly, I'd like to have a better way to
> "get those behaviors fixed" and stop micro-managing, but don't see a viable
> alternative to reviewing commits (except, perhaps, improving the PHB, but
> that's orthogonal to peer reviews and given how often it is being violated,
> it's highly unlikely that it would replace them in a foreseeable future).
The main opposition I have is when "svn blame" is given as a reason.
I've actually heard to not do change that would be done on a new port
simply to avoid making blame harder to read.
Sorry, I disagree strongly with this concept. The "right thing" takes
precedence over blame, and I define the "right thing" as something a
brand new port would have. Secondly, I *rare* use blame; I rarely need
it. If I absolutely have to know who did what and what else was done,
then I'll just have to bite the bullet and trace it through several commits.
Speaking for myself, I really would like not have "this messes up 'svn
blame'" given as a reason for not making a (subjective) improvement
anymore. I do not care very much about that, and it makes me wonder if
people are using blame all the time and if so, why?
John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?552376AD.7010903>