[arch-projects] [INITSCRIPTS][PATCH 4/6] Use bash case modification to check yes/no

[Igor M Podlesny]

On 12 June 2012 22:08, Tom Gundersen <teg at jklm.no> wrote:
> Hi Igor,

   Hi Tom, thanks for your reply.
>
> Answering off-list, as I think this discussion has exceeded its
> usefulness for most people.

   Sure, I didn't expect such unwelcome and rather hostile reaction.
Neither did I expect borrowing the idea from my isYes branch in such,
well, *weird* way as well.

   But I'd prefer answering to the list back.

[…]
>>> 1) doesn't apply to master
>>
>>   What a tragedy. Are you git newcomer, aren't you?
>
> This is a trivial patch, and as such I would appreciate not having to
> resolve conflicts (I'm happy to do that if you have a big complex
> branch for me to merge where rebasing it might not be the best idea).

   Look, it was just a draft branch. That's why it had both /bin/sh
and bash' versions.

>>> 2) adds dead code
>>
>>   "Dead code" doesn't bite, don't be afraid, boy.
>
> We don't add dead code.

   I don't urge anyone to do that. My answer to the 1st item above has
explained why it was there. It could be eliminated on every following
stage easily.

>>> 3) uses camelCase where we use lower_case everywhere else
>>
>>   Yeah, I remember yours strict consistency comparing either "yYeEsS"
>> or "YyEeSs" ;-P
>
> Please follow the current coding style. It contains inconsistencies,
> but we want to reduce them.

   It surely does. It has as [[ ]] && {} and if [[  ]]; then. I just
don't see any guidelines available to follow — are there any?

>>> 4) fails to quote properly
>>
>>   Another tragedy. Feel free to submit patches, dude.
>
> Just to clarify how we work: we don't accept patches with known
> deficiencies, but rather point them out and wait for a fixed patch to
> be resubmitted. I believe this is how most open-source projects work.

   It would be nice and pretty w/o such hostile reaction from Dave.

>>   Show me your code which doesn't suck, then ask my respect.
>
> I'd suggest using "git blame" or "git log". Or even checking out
> mkinitcpio or pacman. Dave knows what he is doing, I suggest listening
> to him.

   You mean "going away"? :)

> As to the patch itself: avoiding duplication of code is generally a
> good thing. Though in this case the code is SO trivial that the
> benefit is minimal. Also, it would mean that people would have to look
> up the function to check if there are any "gotchas" in it, rather than
> just reading it off inline. These things have to be weighted against
> each other. Finally, there is the consideration that whenever we add a
> patch, no matter how trivial, there is a chance that a bug is
> introduced, so we are biased against not adding patches unless the
> benefit is clear.

   It's quite clear benefits. Getting rid of tedious each-time and
each-place comparing is benefit. And looking up a function is what
programmers should be get used to as walking on theirs foots. It's
kinda nonsense to excuse avoiding subroutine use by that reason.

> As to your rather condescending email about subroutines, thanks for
> that, but I am well aware of the basics of the theory of programming
> languages (it being  my day-job).
>
> -t

   Okay.

-- 
End of message. Next message?