On Fri, Dec 11, 2015 at 13:44:03 +0100, Mariusz Mazur wrote: > Somebody needs it, somebody does it.
When sb needs to break compatibility he is allowed to do so? Seriously? > Regarding issues and bugs that happen: don't know where you work, princess, > but where I do everybody regularly makes mistakes and introduces problems by > accident when making changes. Standard procedure is to *not* be a dick while > pointing out other peoples' mistakes. These changes are CLEARLY breaking compatibility - I don't blame anyone for making technical mistakes, but for intentional change. If that wasn't intentional, well... I don't want to point out incompetence, so please don't make me. > Now, I understand that it's tradition to be a dick to other people in PLD, > so, > for old times' sake, why not, seems you're fond of traditions. That tradition had a reason. Flameless issues simply got ignored (fix it yourself, I don't care) and that caused what you call 'tradition'. In older days I would simply revert these changes as breaking compat with some rude comment - consider my current behaviour as less dicky. > not eat anybody's babies. If he introduces issues, describe where the bug is > (at least to the extent that your communication??? skills allow), Both commits I've pointed out are simply bogus. That's it. > hey, maybe fix it yourself if you understand the problem well. If I knew the INTENTIONS of these changes, I might be able to help. But I see none - all my fixing would be reverting them. I gave the author a chance to explain or fix. Instead he has 'fixed' mldonkey... I know why su was replaced by runuser and that's all. WHY does: "daemon: makepid implies fork"? I've just checked once again - no, there's no explanation. How can I fix the code that is not valid and was ...pointless? (don't know). > But no, you don't get to just threaten reversing everything like that. I don't like: 1. putting "makepid implies fork" in daemon() and nesting 'if [ "$makepid" ] ' within 'if [ "$fork" = "1" ]' in _daemon_exec() - this is splitted logic that should be avoided whenever possible; now it LOOKS like it's broken (is it?) and eventually someone will fix that, 2. extracting entire _daemon_exec() from _daemon() - the former one handles variables which are parset by latter one (and passed via $@). Rationale "this will ease understanding it's logic and avoid bugs" is, well, funny? 3. rewriting $@ which is error prone like, by analogy - accessing array by hardcoded index and not a (hash) key. This style of coding has it's name: bad coding practice. And we didn't have to wait too long to expose bugs. > And if this takes longer to fix cause you're being a dick about it and glen > gets discouraged from working on it for a while, that's all on you and > your??? > traditionalism. I can't fix this code other way that rolling back to the previous one, which was FINE. So tell me please, what was wrong before? What was he going to acomplish? THEN I might be able to help with proper solution. Until that moment all I can do is being a dick as you named. -- Tomasz Pala <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
