Skrypty startowe mldonkey

Tomasz Pala gotar at polanet.pl
Fri Dec 11 14:58:29 CET 2015


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 <gotar at pld-linux.org>


More information about the pld-devel-en mailing list