Front page | perl.perl5.porters |
Postings from June 2016
Re: [PATCH] - fix for Coro (was Re: revert MG consting (Corobreakage) for 5.24?)
Thread Previous
|
Thread Next
From:
Marc Lehmann
Date:
June 22, 2016 05:03
Subject:
Re: [PATCH] - fix for Coro (was Re: revert MG consting (Corobreakage) for 5.24?)
Message ID:
20160621034014.GA3426@schmorp.de
On Mon, Jun 20, 2016 at 05:00:01PM +0100, Dave Mitchell <davem@iabyn.com> wrote:
> I have Cc'ed Marc - it's in his hands now whether he wants to incorporate
> them, but p5p's involvement in fixing Coro should be at an end now.
Thanks for this list and explanations - in the interest of users I will
likely bulge one last time and apply these, if possible (there seems to
be at least one genuine bugfix in there!). I have had reports that these
patches don't actually work completely, however, so I will unfortunately
have to look into these in more detail.
Your attitude, on the other hand, is still atrocious.
P5p's involvement in "fixing" Coro and other modules is never at an end
- as long as p5pers have their current "we give a fuck about modules"
attitude and people (he is just an example) such as zefram who are
obviously completely incompetent but still allowed to break stuff without
any valid rationale or reason, just because they want to are in power, p5p
is the source of the problem, not an independent agent that might involve
itself in maintaining perl as a whole form time to time, at their leisure.
It also doesn't help when p5pers spread fud and bullshit about how modules
abuse internals and are broken, when what is broken is, in fact, perl and
the whole p5pers process, which is incapable of bringing perl forward but
obviously capable of a lot of broken experimental stuff that only seems to
break CPAN, and thus Perl (the more important brother of perl). It doesn't
help when p5pers make up bullshit about how trivial it is for modules to
work around their breakage, and then need years to come up with something
that even passes tests, either.
It also doesn't help that p5pers obviously have time to change their
censorship policy for mailing lists and blogs with the only goal to
silence people who digress and merely state facts, while not being able to
change their maintenance policy to reflect the reality, despite patches being
available.
This makes everything that p5pers as a whole claim highly suspect, and
seriously questions your honesty as a group.
In short, your continued attitude of silencing dissent, breaking stuff for
fun and spreading fud means you will be the rightful target of criticism,
the source of friction in the community and ultimately reason for perls
further decline into obsolesence.
You can't steal yourself out of responsibility, no matter how often you try.
If you break things needlessly, it's your responsibility to clean up
afterwards. Of course, it would be better not to break things on a whim, but
that seems to require inhuman strength
I, for once, have made it clear that I won't play these games on the back
of the people who actually try to use perl. I left perl because of this,
and on the next major "we break CPAN needlessly" event (given your track
record, probably with 5.26), I will be out again.
P5pers need to change drastically if they want to regain respect for
what they do. And I am certainly not the only one who thinks so: If you
continue like this, I will predict a fatal loss of perl intelligentsia
within the next five years. Already now people leave perl for python
because of the continued breakage-introducing policy of p5pers (that they
acknowledge but refuse to document).
(I haven't proofread things, because I just don't want to waste more time
on a lost cause - the above is raw stream-of-consciousness. Also, if
anybody feels insulted, get a grip or seek help, I am not responsible for
your mental issues).
--
Kay, you are so full of sh*t that it's not funny. You're refusing to
acknowledge your bugs, you refuse to fix them even when a patch is
sent to you, and then you make excuses for the fact that we have to
work around *your* bugs, and say that we should have done so from the
very beginning.
[Linus in http://article.gmane.org/gmane.linux.kernel/1369384]
Thread Previous
|
Thread Next