develooper Front page | perl.perl5.porters | Postings from September 2014

Re: Roadmap/plan for Perl 5?

Thread Previous | Thread Next
Reini Urban
September 22, 2014 15:43
Re: Roadmap/plan for Perl 5?
Message ID:
On Mon, Sep 8, 2014 at 5:11 PM, Ricardo Signes
<> wrote:
> * Reini Urban <> [2014-09-08T15:46:18]
>> Currently discussing anything remotely advanced is not working within the
>> concept of p5p mailing list threads. It's rather doing more harm. Whenever
>> I'm suggesting an improvement, someone will come up and disable the
>> possibility and vice versa, whenever I'm criticizing a performance regression
>> it will stay in.
>> I'll rather wait for new management or devs, as it happened thanksfully with
>> parrot recently, so that the poisonous people will not harm the project
>> anymore and we can go on.
> Reini, I'm not sure what you're hoping to achieve with this post.  It can only
> serve to alienate you from the currently active developers.

I'm stating the facts - the elephants in the building - as most you
seem to ignore it
or are technically not able to see it.

> While it's possible that some future set of developers working on the project will look
> back on this post and feel retroactively praised and thus more amiable toward
> you, I'm going to call that a long shot.
> Or maybe you want to so dispirit the currently active developers that they
> slink off, allowing your putative "new guard" to take over.  That, I will not
> allow.

They can resign as Nick did, or maybe start acting reasonable and
I don't have a "new guard" to take over. Otherwise we would have
forked off perl5 already.

I had to create my own replacement vm (p2), and I'm still maintaining
the old vm (parrot),
which ought to replace the outdated vm (perl5), until parrot was destroyed by a
different set of poisonous people. Now without them progress can
continue, even of
most of devs choose to switch to the new vm moar, which is simplier,
faster, but with
unscalable threads. This and rakudo bootstrapping is a completely
different elephant
in the room I hope to solve in parallel. Just for historical context.

Informed talking about the issues needs to state the issues.

> You need to make a decision:  play ball or get off the field.

I would rather appreciate if your devs will finally start using to "play ball".
That's the goal. It's only p5p committers which are actively harming
sanity and progress.
They are actively making things worse, actively blocking progress and actively
destroying informed discussion (I called it trolling).
You, management, just fail to call them out and revert them.
Typical management mistakes, as adding bad patches or perf. regressions
directly to blead instead of a branch, discuss it, and refuse to
revert the mess if already done.
That's your problem as a non-technical "community" or "peoples"
manager, as your
are not able to control your rogue devs. This is happening for years.
In a properly managed project this does not happen. It doesn't need to
be such a shark tank,
with certain child actors executing their powers.

And for your listening pleasure: With the new completely insane
SVf_PROTECT bit in blead
to do SVf_READONLY I'm already "off the field". No chance to continue
going on from there.
Good luck with controlling this new elephant.

I can now only summarize the continuous destruction in external blog posts.
Reini Urban

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About