Closed p5pRT closed 6 years ago
p5pRT
commented
6 years ago The smartmatch changes merged in commit da4e040f42421764ef069371d77c008e6b801f45 break some CPAN modules. The first known breakages\, because they're dual-life and had to be customised in blead\, are autodie [rt.cpan.org #123898] and experimental [rt.cpan.org #123899].
p5pRT
commented
6 years ago Also affected: ETHER/Try-Tiny-0.28.tar.gz
-- andreas
p5pRT
commented
6 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
6 years ago Also affected:
RURBAN/B-Keywords-1.15.tar.gz DROLSKY/DateTime-Format-Strptime-1.74.tar.gz FREW/DBIx-Class-Candy-0.005003.tar.gz PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz ABIGAIL/Regexp-Common-2017060201.tar.gz FREW/Syntax-Keyword-Junction-0.003008.tar.gz
-- andreas
p5pRT
commented
6 years ago Also affected: POWERMAN/Async-Defer-v1.0.0.tar.gz MNF/JavaScript-Prepare-v0.1.tar.gz SCHWIGON/Data-DPath-0.57.tar.gz DOHERTY/Lingua-Boolean-0.008.tar.gz TOBYINK/Lingua-Boolean-Tiny-0.007.tar.gz TOBYINK/match-simple-0.010.tar.gz RJBS/Number-Tolerant-1.708.tar.gz PEVANS/Tangence-0.24.tar.gz XIONG/developer-tools/Test-Ranger-v0.0.4.tar.gz PERLANCAR/Org-Parser-0.54.tar.gz CHILTS/XML-Assert-0.03.tar.gz BDFOY/Unicode-Tussle-1.111.tar.gz
-- andreas
p5pRT
commented
6 years ago On Sun\, Dec 17\, 2017 at 12:35 PM\, Zefram \perlbug\-followup@​perl\.org wrote:
The smartmatch changes merged in commit da4e040f42421764ef069371d77c008e6b801f45 break some CPAN modules. The first known breakages\, because they're dual-life and had to be customised in blead\, are autodie [rt.cpan.org #123898] and experimental [rt.cpan.org #123899].
Smart::Match and threads::lite are also affected.
Leon
p5pRT
commented
6 years ago Also affected\, found by Slaven:
DBAURAIN/Bio-MUST-Drivers-0.173510.tar.gz
-- andreas
p5pRT
commented
6 years ago Also affected:
BMORROW/Config-TinyDNS-1.tar.gz SHARYANTO/Data-Dump-Partial-0.05.tar.gz PERLANCAR/Data-Unixish-1.56.tar.gz JALDHAR/DateTime-Calendar-Discordian-1.0.tar.gz CFAERBER/DateTime-Format-DBI-0.041.tar.gz JROCKWAY/Devel-InPackage-0.01.tar.gz SEANO/Exception-Resumable-0.91.tar.gz LEMBARK/Exporter-Proxy-1.8.tar.gz SIFUKURT/File-Butler-v4.0.0.tar.gz AERDAN/File-XDG-0.04.tar.gz DCONWAY/IO-Prompter-0.004014.tar.gz PATCH/Operator-Util-0.05.tar.gz JROCKWAY/Package-FromData-0.01.tar.gz
-- andreas
p5pRT
commented
6 years ago Also affected:
* CHRISBR/Test-Mockify-1.0.tar.gz * DCONWAY/Lingua-EN-Inflexion-0.001006.tar.gz * JJNAPIORK/Catalyst-Runtime-5.90115.tar.gz * LEONT/experimental-0.019.tar.gz * MAROS/MooseX-App-1.39.tar.gz * PERLANCAR/DBIx-Diff-Schema-0.090.tar.gz * PERLANCAR/Data-Sah-0.88.tar.gz * PERLANCAR/Module-XSOrPP-0.11.tar.gz * PERLANCAR/Perinci-Sub-DepChecker-0.11.tar.gz * PERLANCAR/Perl-Stripper-0.10.tar.gz * PERLANCAR/Progress-Any-Output-TermProgressBarColor-0.23.tar.gz * PERLANCAR/Text-ANSITable-0.49.tar.gz * PERLANCAR/Unix-Passwd-File-0.250.tar.gz * PJF/autodie-2.29.tar.gz * TOBYINK/lexical-underscore-0.004.tar.gz * VPIT/Scope-Upper-0.30.tar.gz (compilation error)
Sorry for any possible duplicates --- the many lists are hard to track. I did not omit dual-life modules which are already fixed in core. Actually I did not do a thorough check if these are really affected because of #132594\, or due to other reasons.
BTW\, I stopped my regular 5.27.7 smoker runs and switched back to the last bleadperl without any major breakages (5.27.5). I won't also do complete CPAN checks like I used to do with former bleadperl versions.
Regards\, Slaven
--
Slaven Rezic - slaven \
Berlin Perl Mongers - http://berlin.pm.org
p5pRT
commented
6 years ago On Sat\, Dec 23\, 2017 at 10:45 AM\, Slaven Rezic \slaven@​rezic\.de wrote:
Also affected:
\* CHRISBR/Test\-Mockify\-1\.0\.tar\.gz \* DCONWAY/Lingua\-EN\-Inflexion\-0\.001006\.tar\.gz \* JJNAPIORK/Catalyst\-Runtime\-5\.90115\.tar\.gz \* LEONT/experimental\-0\.019\.tar\.gz \* MAROS/MooseX\-App\-1\.39\.tar\.gz \* PERLANCAR/DBIx\-Diff\-Schema\-0\.090\.tar\.gz \* PERLANCAR/Data\-Sah\-0\.88\.tar\.gz \* PERLANCAR/Module\-XSOrPP\-0\.11\.tar\.gz \* PERLANCAR/Perinci\-Sub\-DepChecker\-0\.11\.tar\.gz \* PERLANCAR/Perl\-Stripper\-0\.10\.tar\.gz \* PERLANCAR/Progress\-Any\-Output\-TermProgressBarColor\-0\.23\.tar\.gz \* PERLANCAR/Text\-ANSITable\-0\.49\.tar\.gz \* PERLANCAR/Unix\-Passwd\-File\-0\.250\.tar\.gz \* PJF/autodie\-2\.29\.tar\.gz \* TOBYINK/lexical\-underscore\-0\.004\.tar\.gz \* VPIT/Scope\-Upper\-0\.30\.tar\.gz \(compilation error\)Sorry for any possible duplicates --- the many lists are hard to track. I did not omit dual-life modules which are already fixed in core. Actually I did not do a thorough check if these are really affected because of #132594\, or due to other reasons.
BTW\, I stopped my regular 5.27.7 smoker runs and switched back to the last bleadperl without any major breakages (5.27.5). I won't also do complete CPAN checks like I used to do with former bleadperl versions.
IMNSHO this breakage is irresponsible and madness. None of this is necessary at all: we can easily enable the old behavior under use 5.010 .. 5.026\,and and the new one on use 5.028+\, that way we could have new potentially better smartmatch without fucking over everyone who has been using it over the past decade.
I really don't get how to got into this situation. It feels to me like in search for some sense of purity we lost all consideration for our user base. We had a little discussion on what the new behavior should look like\, but none at all about deal with the transition. It's almost like we're deliberately trying to fuck ourselves over.
Leon
p5pRT
commented
6 years ago On 12/23/2017 07:39 AM\, Leon Timmermans wrote:
On Sat\, Dec 23\, 2017 at 10:45 AM\, Slaven Rezic \<slaven@rezic.de \mailto​:slaven@​rezic\.de> wrote:
Also affected​: \* CHRISBR/Test\-Mockify\-1\.0\.tar\.gz \* DCONWAY/Lingua\-EN\-Inflexion\-0\.001006\.tar\.gz \* JJNAPIORK/Catalyst\-Runtime\-5\.90115\.tar\.gz \* LEONT/experimental\-0\.019\.tar\.gz \* MAROS/MooseX\-App\-1\.39\.tar\.gz \* PERLANCAR/DBIx\-Diff\-Schema\-0\.090\.tar\.gz \* PERLANCAR/Data\-Sah\-0\.88\.tar\.gz \* PERLANCAR/Module\-XSOrPP\-0\.11\.tar\.gz \* PERLANCAR/Perinci\-Sub\-DepChecker\-0\.11\.tar\.gz \* PERLANCAR/Perl\-Stripper\-0\.10\.tar\.gz \* PERLANCAR/Progress\-Any\-Output\-TermProgressBarColor\-0\.23\.tar\.gz \* PERLANCAR/Text\-ANSITable\-0\.49\.tar\.gz \* PERLANCAR/Unix\-Passwd\-File\-0\.250\.tar\.gz \* PJF/autodie\-2\.29\.tar\.gz \* TOBYINK/lexical\-underscore\-0\.004\.tar\.gz \* VPIT/Scope\-Upper\-0\.30\.tar\.gz \(compilation error\) Sorry for any possible duplicates \-\-\- the many lists are hard to track\. I did not omit dual\-life modules which are already fixed in core\. Actually I did not do a thorough check if these are really affected because of \#132594\, or due to other reasons\. BTW\, I stopped my regular 5\.27\.7 smoker runs and switched back to the last bleadperl without any major breakages \(5\.27\.5\)\. I won't also do complete CPAN checks like I used to do with former bleadperl versions\.
That seems wise. The data I've been assembling on the CPAN-river-1000 (presented in other posts) shows considerably increased breakage from the November and December releases.
IMNSHO this breakage is irresponsible and madness. None of this is necessary at all: we can easily enable the old behavior under use 5.010 .. 5.026\,and and the new one on use 5.028+\, that way we could have new potentially better smartmatch without fucking over everyone who has been using it over the past decade.
I really don't get how to got into this situation. It feels to me like in search for some sense of purity we lost all consideration for our user base. We had a little discussion on what the new behavior should look like\, but none at all about deal with the transition. It's almost like we're deliberately trying to fuck ourselves over.
I concur. We are now less than one-month away from the point in the annual dev cycle after which nothing "contentious" may be committed to blead (Jan 20 2018). All this breakage is contentious by definition.
Thank you very much. Jim Keenan
p5pRT
commented
6 years ago Leon Timmermans wrote:
we can easily enable the old behavior under use 5\.010 \.\.5.026\,and and the new one on use 5.028+\,
That's neither sensible nor really workable. It would not be sensible because it would involve retaining and maintaining all of the overcomplex old behaviour indefinitely. It would have to stay in the documentation\, and users would have to be aware of it as a feature they might see used in Perl programs. It would be a substantial burden all round. The feature has been marked experimental for years precisely so that we would not be obliged to keep all of this; it was explicitly intended that we would in fact change it. This is what experimental status is for.
Hypothetically\, if we did implement dual behaviour\, that still wouldn't just avoid this breakage. If smartmatch overloading is a single hook\, such that 5.10 code and 5.28 code using their respective smartmatch operators invoke the same smartmatch overload methods\, then there is a problem in constructing higher-order smartmatch objects\, such as Smart::Match's junctions. Smartmatching means different things for different code\, so it's no longer possible to pass a smartmatcher across an API boundary and have that have a consistent meaning. Does any() take 5.10 smartmatchers? That's how its arguments will be interpreted if Smart::Match remains unchanged\, written in 5.10 code. How do you do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? And so on; the variations are obvious. The only way to keep the behaviour really compatible would be for 5.10 smartmatch and 5.28 smartmatch to have separate overload hooks\, but then you need duplicates of all of Smart::Match\, and people will get them confused.
without fucking over everyone who has beenusing it over the past decade.
If 5.10-style smartmatch is so significantly used that it's not acceptable to remove it\, this is the wrong point at which to raise that issue. It's not an argument for not changing an ill-designed experimental feature; it's an argument for taking it out of experimental status.
We had a little discussion on what the new behavior should look like\,but none at all about deal with the transition.
It seemed quite obvious how to transition. We determined long ago that the changes we'd make would be extensive\, and would leave little compatibility with the old version of the feature. It's an experimental feature\, so we're free to change things without a deprecation cycle. Hence the most reasonable course of action is a one-time breaking change with no attempt to be compatible. Furthermore\, if there are any other incompatible changes we might be interested in then it's best to group them all together into this one big break of compatibility.
-zefram
p5pRT
commented
6 years ago Also affected:
LEMBARK/Parallel-Queue-3.6.tar.gz SGLADKOV/Redis-CappedCollection-1.10.tar.gz MAJENSEN/REST-Neo4p-0.3020.tar.gz BBYRD/sanity-1.03.tar.gz MATIU/SQL-Bibliosoph-2.55.tar.gz TAPPER/Tapper-Installer-5.0.0.tar.gz DOY/Try-0.03.tar.gz
-- andreas
p5pRT
commented
6 years ago I'll let Leon to respond to the technical details. I want to address the overall breakage this has caused.
On first blush\, it seems like too many things are breaking. On second thought\, smart match had always been experimental. However\, my current thoughts are back to "too many things are breaking." This breakage is considerable and the harm it will have on CPAN is vast. While we do reserve the right to change the syntax (because it's experimental)\, it does not mean we must do it right now. We should exercise judgment and err on the side of caution.
The most telling email for me on this thread was Slaven saying he stopped smoke testing on 5.27.7 because too many things were breaking due to this.
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1]. Smart match has waited this long\, it can wait another release in hopes of getting it right. (Perhaps we will also find alternatives for "whereis" and "whereso" meanwhile.)
[1] This is currently only a suggestion\, but unless someone comes up with something better\, this is what we should do.
On 12/23/2017 04:44 PM\, Zefram wrote:
Leon Timmermans wrote:
we can easily enable the old behavior under use 5\.010 \.\.5.026\,and and the new one on use 5.028+\, That's neither sensible nor really workable. It would not be sensible because it would involve retaining and maintaining all of the overcomplex old behaviour indefinitely. It would have to stay in the documentation\, and users would have to be aware of it as a feature they might see used in Perl programs. It would be a substantial burden all round. The feature has been marked experimental for years precisely so that we would not be obliged to keep all of this; it was explicitly intended that we would in fact change it. This is what experimental status is for.
Hypothetically\, if we did implement dual behaviour\, that still wouldn't just avoid this breakage. If smartmatch overloading is a single hook\, such that 5.10 code and 5.28 code using their respective smartmatch operators invoke the same smartmatch overload methods\, then there is a problem in constructing higher-order smartmatch objects\, such as Smart::Match's junctions. Smartmatching means different things for different code\, so it's no longer possible to pass a smartmatcher across an API boundary and have that have a consistent meaning. Does any() take 5.10 smartmatchers? That's how its arguments will be interpreted if Smart::Match remains unchanged\, written in 5.10 code. How do you do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? And so on; the variations are obvious. The only way to keep the behaviour really compatible would be for 5.10 smartmatch and 5.28 smartmatch to have separate overload hooks\, but then you need duplicates of all of Smart::Match\, and people will get them confused.
without fucking over everyone who has beenusing it over the past decade. If 5.10-style smartmatch is so significantly used that it's not acceptable to remove it\, this is the wrong point at which to raise that issue. It's not an argument for not changing an ill-designed experimental feature; it's an argument for taking it out of experimental status.
We had a little discussion on what the new behavior should look like\,but none at all about deal with the transition. It seemed quite obvious how to transition. We determined long ago that the changes we'd make would be extensive\, and would leave little compatibility with the old version of the feature. It's an experimental feature\, so we're free to change things without a deprecation cycle. Hence the most reasonable course of action is a one-time breaking change with no attempt to be compatible. Furthermore\, if there are any other incompatible changes we might be interested in then it's best to group them all together into this one big break of compatibility.
-zefram
p5pRT
commented
6 years ago On 12/24/2017 10:43 AM\, Sawyer X wrote:
I'll let Leon to respond to the technical details. I want to address the overall breakage this has caused.
On first blush\, it seems like too many things are breaking. On second thought\, smart match had always been experimental. However\, my current thoughts are back to "too many things are breaking." This breakage is considerable and the harm it will have on CPAN is vast. While we do reserve the right to change the syntax (because it's experimental)\, it does not mean we must do it right now. We should exercise judgment and err on the side of caution.
The most telling email for me on this thread was Slaven saying he stopped smoke testing on 5.27.7 because too many things were breaking due to this.
I think we need to take a step back\, revert this change
+1
\, and figure out
a plan to move forward[1]. Smart match has waited this long\, it can wait another release in hopes of getting it right. (Perhaps we will also find alternatives for "whereis" and "whereso" meanwhile.)
[1] This is currently only a suggestion\, but unless someone comes up with something better\, this is what we should do.
On 12/23/2017 04:44 PM\, Zefram wrote:
Leon Timmermans wrote:
we can easily enable the old behavior under use 5\.010 \.\.5.026\,and and the new one on use 5.028+\, That's neither sensible nor really workable. It would not be sensible because it would involve retaining and maintaining all of the overcomplex old behaviour indefinitely. It would have to stay in the documentation\, and users would have to be aware of it as a feature they might see used in Perl programs. It would be a substantial burden all round. The feature has been marked experimental for years precisely so that we would not be obliged to keep all of this; it was explicitly intended that we would in fact change it. This is what experimental status is for.
Hypothetically\, if we did implement dual behaviour\, that still wouldn't just avoid this breakage. If smartmatch overloading is a single hook\, such that 5.10 code and 5.28 code using their respective smartmatch operators invoke the same smartmatch overload methods\, then there is a problem in constructing higher-order smartmatch objects\, such as Smart::Match's junctions. Smartmatching means different things for different code\, so it's no longer possible to pass a smartmatcher across an API boundary and have that have a consistent meaning. Does any() take 5.10 smartmatchers? That's how its arguments will be interpreted if Smart::Match remains unchanged\, written in 5.10 code. How do you do any() on 5.28 smartmatchers? What if Smart::Match is reimplemented? And so on; the variations are obvious. The only way to keep the behaviour really compatible would be for 5.10 smartmatch and 5.28 smartmatch to have separate overload hooks\, but then you need duplicates of all of Smart::Match\, and people will get them confused.
without fucking over everyone who has beenusing it over the past decade. If 5.10-style smartmatch is so significantly used that it's not acceptable to remove it\, this is the wrong point at which to raise that issue. It's not an argument for not changing an ill-designed experimental feature; it's an argument for taking it out of experimental status.
We had a little discussion on what the new behavior should look like\,but none at all about deal with the transition. It seemed quite obvious how to transition. We determined long ago that the changes we'd make would be extensive\, and would leave little compatibility with the old version of the feature. It's an experimental feature\, so we're free to change things without a deprecation cycle. Hence the most reasonable course of action is a one-time breaking change with no attempt to be compatible. Furthermore\, if there are any other incompatible changes we might be interested in then it's best to group them all together into this one big break of compatibility.
-zefram
p5pRT
commented
6 years ago On 12/24/2017 12:43 PM\, Sawyer X wrote:
I'll let Leon to respond to the technical details. I want to address the overall breakage this has caused.
On first blush\, it seems like too many things are breaking. On second thought\, smart match had always been experimental. However\, my current thoughts are back to "too many things are breaking." This breakage is considerable and the harm it will have on CPAN is vast. While we do reserve the right to change the syntax (because it's experimental)\, it does not mean we must do it right now. We should exercise judgment and err on the side of caution.
The most telling email for me on this thread was Slaven saying he stopped smoke testing on 5.27.7 because too many things were breaking due to this.
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1]. Smart match has waited this long\, it can wait another release in hopes of getting it right. (Perhaps we will also find alternatives for "whereis" and "whereso" meanwhile.)
[1] This is currently only a suggestion\, but unless someone comes up with something better\, this is what we should do.
+1
As the data which I have been posting suggests\, we already have a lot of CPAN breakage to deal with over the balance of this development cycle\, and over the next four weeks in particular. That's going to be a cognitive load on all of us\, particularly since many people won't be able to focus on it until after the holidays. So if we can avoid a lot of breakage and downstream frustration by only taking measured steps forward\, I say let's do so.
Thank you very much. Jim Keenan
p5pRT
commented
6 years ago On 12/24/2017 06:43 PM\, Sawyer X wrote:
On first blush\, it seems like too many things are breaking. On second thought\, smart match had always been experimental.
Give me a fucking break!
Is the period between 5.10 and 5.18 "ancient history" enough\, for you to top-post-declare how "smart match has always been experimental? [1]
What is the end-game here? In a short time you went from "I have no great plans when it comes to changes to the Perl core"[2] to full blown "make perl great again". Do you *still* feel that /usr/bin/perl ( and its users ) can go fuck itself[3]\, even after a year on the job?
I am not writing this email because I expect you to *change* or because there is a way to make things work with you at the helm. I am writing this because I am pissed. You are an excellent speaker ( whenever you talk about a subject you know )\, a superb story-teller\, and overall an all around decent human being. And all of this is tainted and gone forever\, because you bought into the narrative that "anyone can be president".
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Please grow a pair and resign.
[1] https://metacpan.org/pod/distribution/perl/pod/perl5180delta.pod#The-smartmatch-family-of-features-are-now-experimental [2] https://www.nntp.perl.org/group/perl.perl5.porters/2016/04/msg236028.html [3] https://youtu.be/M-VKSCgIgo0?t=2425
p5pRT
commented
6 years ago On 12/24/2017 02:49 PM\, Peter Rabbitson wrote:
Please grow a pair and resign
-1
p5pRT
commented
6 years ago On Sun\, 24 Dec 2017 22:49:34 +0100 Peter Rabbitson \rabbit\-p5p@​rabbit\.us wrote:
Is the period between 5.10 and 5.18 "ancient history" enough\, for you to top-post-declare how "smart match has always been experimental? [1]
While I don't agree with the rest of this post\, it's an *extremely* important point.
Smartmatch and given/when aren't typical experimental features. They were introduced in 5.10 and they indeed did *not* warn until 5.18. Those features received widespread adoption years before they started warning.
On CPAN alone there are thousands of uses of ~~ and given/when and I'm fairly certain that situation in darkpan is even worse.
Huge portion of perl users aren't using anything never than 5.16.3 (which is the version RHEL 7 ships). Most of them are completely unaware of its current status and continue to use it in new code.
I think that smartmatch changes should be reverted and we need *much* more discussion about them.
p5pRT
commented
6 years ago * Peter Rabbitson \rabbit\-p5p@​rabbit\.us [2017-12-24T16:49:34]
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Please grow a pair and resign.
If you want to have the conversation you're starting in this thread\, this is the right place to start it.
This is not the right tenor to take\, starting reasonably with a complaint about a falsehood\, ramping up toward hyperbole\, and ending with a crude and sexist remark.
"Just anybody can do the job" isn't made any better by tacking on "if they're willing to suffer verbal abuse."
-- rjbs
p5pRT
commented
6 years ago Sawyer X wrote:
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1].
If we can't accept this kind of CPAN breakage then we have no way forward short of deprecation\, and experimental status (about which smartmatch has been warning for much longer than a deprecation cycle) would seem to have no value.
-zefram
p5pRT
commented
6 years ago I do not enjoy you picking the one sentence you want to respond to\, especially when it is the opposite of the complete point I am making. I clarified that I think it should be reverted\, but you looked for me beginning with the counter point so you could have your opening to say what you wanted.
Now considering I've resolved to reverting it\, what is the point you're trying to drive? Convincing me to do what I said we should?
Beyond this\, as I've said to anyone else (and stand by)\, if you cannot make your point without spewing sexist or otherwise offensive behavior\, please take it offline. Or\, you know\, learn to speak like an adult.
On 12/24/2017 11:49 PM\, Peter Rabbitson wrote:
On 12/24/2017 06:43 PM\, Sawyer X wrote:
On first blush\, it seems like too many things are breaking. On second thought\, smart match had always been experimental.
Give me a fucking break!
Is the period between 5.10 and 5.18 "ancient history" enough\, for you to top-post-declare how "smart match has always been experimental? [1]
What is the end-game here? In a short time you went from "I have no great plans when it comes to changes to the Perl core"[2] to full blown "make perl great again". Do you *still* feel that /usr/bin/perl ( and its users ) can go fuck itself[3]\, even after a year on the job?
I am not writing this email because I expect you to *change* or because there is a way to make things work with you at the helm. I am writing this because I am pissed. You are an excellent speaker ( whenever you talk about a subject you know )\, a superb story-teller\, and overall an all around decent human being. And all of this is tainted and gone forever\, because you bought into the narrative that "anyone can be president".
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Please grow a pair and resign.
[1] https://metacpan.org/pod/distribution/perl/pod/perl5180delta.pod#The-smartmatch-family-of-features-are-now-experimental [2] https://www.nntp.perl.org/group/perl.perl5.porters/2016/04/msg236028.html [3] https://youtu.be/M-VKSCgIgo0?t=2425
p5pRT
commented
6 years ago On 12/25/2017 08:21 AM\, Zefram wrote:
Sawyer X wrote:
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1]. If we can't accept this kind of CPAN breakage then we have no way forward short of deprecation\, and experimental status (about which smartmatch has been warning for much longer than a deprecation cycle) would seem to have no value.
Any CPAN breakage of this magnitude needs to be weighed against the value it provides in the short term and in the long term\, as well as any damage of neglecting it includes.
In this case\, there is little loss in not making his change at the moment\, even if we take the slippery slope perspective that "now experimental needs to be deprecated." This breakage is simply too much for us to ignore or accept for just providing a different smart match.
As for the slipper slope argument\, I think this argument suggests we "make a point" of it\, and I do not think that something we should ever do. We shouldn't be "making a point" with our changes to clarify what "experimental" means or to defend its meaning. Same for "deprecated." We follow-up on deprecation because things have been deprecated for a reason\, other than clarifying what "deprecation"' means.
p5pRT
commented
6 years ago On Mon\, Dec 25\, 2017 at 7:21 AM\, Zefram \zefram@​fysh\.org wrote:
Sawyer X wrote:
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1].
If we can't accept this kind of CPAN breakage then we have no way forward short of deprecation\, and experimental status (about which smartmatch has been warning for much longer than a deprecation cycle) would seem to have no value.
There are a few factors here that dramatically reduce the value-for-breakage ratio.
The first is that the level of breakage in smartmatch creates more problems and solves less of them than they could. The problem with it is that it's a 27-way dispatch table: I'm pretty sure we can break «REGEX ~~ HASH» without serious repercussions; but the same is not true of «$foo ~~ "foo"» (that said\, actual data would be way more valuable than my anecdotes). A 4-5 way table guided by what features people actually use could give us something that we can explain without breaking people's expectations unnecessarily. Pareto's principle applies here.
The second problem is that the switch feature it provides no way to write code that works on both 5.26 and 5.28 (this really should have been a design requirement)\, which is effectively equivalent to removing it entirely. Whatever we do we are stuck to when in one way or another.
Thirdly\, this process can be made more gradual. Having the 20+ paths that we would break emit deprecation warnings first would ease the transition.
Lastly\, what happened to the idea of experimenting on CPAN?
So no\, I don't think this kind of breakage is acceptable. That doesn't mean I oppose all change.
Leon
p5pRT
commented
6 years ago On Sun\, Dec 24\, 2017 at 10:49:34PM +0100\, Peter Rabbitson wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
As someone who has been using Perl since 1992\, and who has been working on the perl core since 2001\, I utterly disagree with every part of your inflammatory and unevidenced statement above.
-- No man treats a motor car as foolishly as he treats another human being. When the car will not go\, he does not attribute its annoying behaviour to sin\, he does not say\, You are a wicked motorcar\, and I shall not give you any more petrol until you go. He attempts to find out what is wrong and set it right. -- Bertrand Russell\, Has Religion Made Useful Contributions to Civilization?
p5pRT
commented
6 years ago Sawyer X \xsawyerx@​gmail\.com wrote:
I think we need to take a step back\, revert this change\, and figure out a plan to move forward[1]. Smart match has waited this long\, it can wait another release in hopes of getting it right.
+1. There's far too much breakage here for us to countenance releasing anything akin to what's currently in blead as 5.28.
-- Aaron Crane
p5pRT
commented
6 years ago [Speaking as a moderator]
Peter Rabbitson \rabbit\-p5p@​rabbit\.us wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Peter\, we do not permit personal attacks on perl5-porters. Please take this as a formal warning\, in accordance with our documented Standards of Conduct[1]\, that this behaviour is unacceptable\, and that a repetition of it will result in you being banned from the list.
[1] https://metacpan.org/pod/distribution/perl/pod/perlpolicy.pod#STANDARDS-OF-CONDUCT
-- Aaron Crane
p5pRT
commented
6 years ago On 12/27/2017 12:46 PM\, Aaron Crane wrote:
[Speaking as a moderator]
Peter Rabbitson \rabbit\-p5p@​rabbit\.us wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Peter\, we do not permit personal attacks on perl5-porters. Please take this as a formal warning\, in accordance with our documented Standards of Conduct[1]\, that this behaviour is unacceptable\, and that a repetition of it will result in you being banned from the list.
In order for the warning to be acknowledged by its receiver\, common sense requires an explicit highlight of the violation.
The part you quoted *specifically* speaks of the pumpkin's job performance. I explicitly avoided making negative statements about his personal character\, in fact I explicitly spelled out quite the opposite.
Please clarify your concerns as a moderator.
Cheers
p5pRT
commented
6 years ago Peter Rabbitson \rabbit\-p5p@​rabbit\.us wrote:
On 12/27/2017 12:46 PM\, Aaron Crane wrote:
[Speaking as a moderator]
Peter Rabbitson \rabbit\-p5p@​rabbit\.us wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
Peter\, we do not permit personal attacks on perl5-porters. Please take this as a formal warning\, in accordance with our documented Standards of Conduct[1]\, that this behaviour is unacceptable\, and that a repetition of it will result in you being banned from the list.
In order for the warning to be acknowledged by its receiver\, common sense requires an explicit highlight of the violation.
The part you quoted *specifically* speaks of the pumpkin's job performance. I explicitly avoided making negative statements about his personal character\, in fact I explicitly spelled out quite the opposite.
Please clarify your concerns as a moderator.
The Standards of Conduct read as follows:
* Always be civil. * Heed the moderators.
Civility is simple: stick to the facts while avoiding demeaning remarks and sarcasm. It is not enough to be factual. You must also be civil.
While civility is required\, kindness is encouraged; if you have any doubt about whether you are being civil\, simply ask yourself\, "Am I being kind?" and aspire to that.
If the list moderators tell you that you are not being civil\, carefully consider how your words have appeared before responding in any way. Were they kind? You may protest\, but repeated protest in the face of a repeatedly reaffirmed decision is not acceptable.
Unacceptable behavior will result in a public and clearly identified warning. Repeated unacceptable behavior will result in removal from the mailing list and revocation of rights to update rt.perl.org.
Phrases like "irredeemable failure"\, "embarrassment"\, and "feverishly butchering" are demeaning. They are not civil\, and they are certainly not kind.
To be clear: I am reaffirming my decision that your behaviour above was unacceptable\, and I will not engage in further discussion of that decision. If you don't see your comments as uncivil and unkind\, all I can suggest is that in future you seek input from other people on any draft messages before sending them.
-- Aaron Crane
p5pRT
commented
6 years ago On Wed\, 27 Dec 2017 13:26:14 +0000\, Aaron Crane \arc@​cpan\.org said:
> Phrases like "irredeemable failure"\, "embarrassment"\, and "feverishly > butchering" are demeaning. They are not civil\, and they are certainly > not kind.
> To be clear: I am reaffirming my decision that your behaviour above > was unacceptable\, and I will not engage in further discussion of that > decision. If you don't see your comments as uncivil and unkind\, all I > can suggest is that in future you seek input from other people on any > draft messages before sending them.
moderation-- # please learn to look away when you are not needed
-- andreas
p5pRT
commented
6 years ago On Wed\, Dec 27\, 2017 at 11:34 AM\, Andreas Koenig \< andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
On Wed\, 27 Dec 2017 13:26:14 +0000\, Aaron Crane \arc@​cpan\.org said:
Phrases like "irredeemable failure"\, "embarrassment"\, and "feverishly butchering" are demeaning. They are not civil\, and they are certainly not kind.
To be clear: I am reaffirming my decision that your behaviour above was unacceptable\, and I will not engage in further discussion of that decision. If you don't see your comments as uncivil and unkind\, all I can suggest is that in future you seek input from other people on any draft messages before sending them.
moderation-- # please learn to look away when you are not needed
I disagree\, this was quite needed. Peter's comments\, specifically how they were presented\, are not conducive to rational discussion and contribute to a hostile environment. Just my opinion.
-Dan
p5pRT
commented
6 years ago * Andreas Koenig \andreas\.koenig\.7os6VVqR@​franz\.ak\.mind\.de [2017-12-27T11:34:23]
moderation-- # please learn to look away when you are not needed
I found your brief message ambiguous.
Could you clarify whether you mean:
1. Everything here was civil\, and this is the kind of tone of conversation that people contributing to p5 should accept. Moderation is sometimes required\, but here it was not.
2. Moderation itself is a bad idea\, as it inhibits useful conversation.
3. Moderation is sometimes required. Other times\, in the face of incivility\, the moderators should look away so that somebody who needs to be berated can be.
-- rjbs
p5pRT
commented
6 years ago On Wed\, 27 Dec 2017 12:38:37 -0500\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org said:
> * Andreas Koenig \andreas\.koenig\.7os6VVqR@​franz\.ak\.mind\.de [2017-12-27T11:34:23]
moderation-- # please learn to look away when you are not needed
> I found your brief message ambiguous.
> Could you clarify whether you mean:
> 1. Everything here was civil\, and this is the kind of tone of conversation > that people contributing to p5 should accept. Moderation is sometimes > required\, but here it was not.
> 2. Moderation itself is a bad idea\, as it inhibits useful conversation.
> 3. Moderation is sometimes required. Other times\, in the face of > incivility\, the moderators should look away so that somebody who needs to > be berated can be.
Well\, no\, sorry\, none looks appropriate. Rather these:
4. Moderation can come in many flavours\, some of which are better than others.
5. A moderation system like on p5p where a single person can define that certain phrases shall be punished with a life-long ban\, is not one of the better ones.
6. The incriminated posting was already rejected by yourself and several others and Sawyer had answered in sovereignty (at least did I perceive it as such) and there was already a chance that the discourse could go on. No need for moderation at all.
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
-- andreas
p5pRT
commented
6 years ago * Andreas Koenig \andreas\.koenig\.7os6VVqR@​franz\.ak\.mind\.de [2017-12-27T18:18:47]
On Wed\, 27 Dec 2017 12:38:37 -0500\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org said:
I found your brief message ambiguous. Could you clarify whether you mean: [options]
Well\, no\, sorry\, none looks appropriate. Rather these:
Thanks\, I meant to include "Or something else" and forgot.
5. A moderation system like on p5p where a single person can define that certain phrases shall be punished with a life-long ban\, is not one of the better ones.
This is not really what we have at all. I think there has been one long-term ban issued\, outside the rules of the system\, by me\, after long and sustained incivility. In all other cases\, what you describe is not what happens.
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
Here is another way to look at it: The project manager is already dealing with a load of crap\, and piling abuse on top of complaint is doubly stressful. Complaints must be welcomed. Abuse must be turned away. Having a standard of behavior is a way to ensure that the job is obnoxious only for *necessary* reasons.
Following through on the policy every time it is warranted makes it clear that it is a routine\, and the most effective way to avoid the hassle of hearing about it is to keep a civil tongue in the first place.
-- rjbs
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 12:18 AM\, Andreas Koenig \< andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
We can stop people from saying unkind things\, but how are we going to prevent repeats of this utter fuck-up\, given that this "process" could have only resulted in a fuck-up?
Are we going to politely destroy perl?
Leon
p5pRT
commented
6 years ago On Dec 27\, 2017 11:53 PM\, "Leon Timmermans" \fawaka@​gmail\.com wrote:
On Thu\, Dec 28\, 2017 at 12:18 AM\, Andreas Koenig \< andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
We can stop people from saying unkind things\, but how are we going to prevent repeats of this utter fuck-up\, given that this "process" could have only resulted in a fuck-up?
Are we going to politely destroy perl?
Leon
I don't understand why these topics need to be conflated\, and don't find that ironic whatsoever. This list has had a straightforward moderation process for a long time\, something that takes very different expertise and procedures to execute effectively than language design. Can we focus on how that can be improved?
-Dan
p5pRT
commented
6 years ago On Dec 27\, 2017 11:53 PM\, "Leon Timmermans" \fawaka@​gmail\.com wrote:
Are we going to politely destroy perl?
Now\, I agree that there is some flaw in the process here and these changes were not ready to be merged. But this is a funny thing people keep saying. That making changes\, or making mistakes\, is killing Perl.
Outside our little echo chamber most think Perl is dead. They think that because they don't know it's still being used\, or still being developed. They think it's abandoned. Some of this is because of Perl 6\, or that period of time where it really wasn't being developed. Some of it is because it's been outshined in popularity and buzzwords by the next three big things\, which by the way\, C and Java and the like don't directly compete with. But they're not saying it's dead because it broke some compatibility.
The reality is that there is no absolute one decision to make in every situation. Managing this language's continued development is a complex balancing act and the continued implications that there are simple answers and one person or another is instead sabotaging Perl are dishonest outlets for dissatisfaction that do no favors to anyone.
-Dan
p5pRT
commented
6 years ago On 28 December 2017 at 21:28\, Dan Book \grinnz@​gmail\.com wrote:
Outside our little echo chamber most think Perl is dead. They think that because they don't know it's still being used\, or still being developed.
The people who think Perl is dead do not matter what so ever. They're allowed to be wrong.
The only people who matter are the people who are already using Perl\, and the people who want to use Perl in the future.
Changing what Perl is to suit the first group\, while making it useless to the second group\, pretty much invalidates the point of even having different programming languages.
If the design objective of Perl is to be another Ruby or JavaScript\, well\, why don't we just use those languages then?
"Popularity" is not a meaningful metric on its own\, because you can be popular due to being popular\, not due to being objectively decent. ( Paying attention to politics should make this abundantly clear )
If people want to think Ruby or JavaScript are "cooler" than Perl or "more modern"\, cool\, they can do that.
But those are languages where people who presently use Perl frequently find too chaotic to be worth their time investment.
Making Perl more chaotic to be cool like them is simply corroding the remaining reasons to use Perl.
-- Kent
KENTNL - https://metacpan.org/author/KENTNL
p5pRT
commented
6 years ago On Wed\, 27 Dec 2017 18:45:57 -0500\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org said:
5. A moderation system like on p5p where a single person can define that certain phrases shall be punished with a life-long ban\, is not one of the better ones.
> This is not really what we have at all. I think there has been one long-term > ban issued\, outside the rules of the system\, by me\, after long and sustained > incivility. In all other cases\, what you describe is not what happens.
Darn\, I stand corrected. I only recently learned about the long-term ban and misunderstood it as the normal case. Maybe it would be a good idea to reset the one long-term ban now. I don't think it still serves a good purpose.
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
> Here is another way to look at it: The project manager is already dealing with > a load of crap\, and piling abuse on top of complaint is doubly stressful. > Complaints must be welcomed. Abuse must be turned away. Having a standard of > behavior is a way to ensure that the job is obnoxious only for *necessary* > reasons.
> Following through on the policy every time it is warranted makes it clear that > it is a routine\, and the most effective way to avoid the hassle of hearing > about it is to keep a civil tongue in the first place.
Granted\, this is a way to look at it. I'd still prefer that the moderation routine should rather kick in as a last ressort than too soon\, but given that the harm is smaller than I had thought\, I see no value in fighting over it.
Thanks for the correction\, -- andreas
p5pRT
commented
6 years ago Andreas Koenig \andreas\.koenig\.7os6VVqR@​franz\.ak\.mind\.de wrote:
5. A moderation system like on p5p where a single person can define that certain phrases shall be punished with a life-long ban\, is not one of the better ones.
6. The incriminated posting was already rejected by yourself and several others and Sawyer had answered in sovereignty (at least did I perceive it as such) and there was already a chance that the discourse could go on. No need for moderation at all.
7. We have to deal with a highly problematic blead branch with an unprecendented level of breakage. I find it double problematic when moderation kicks in while we have a huge mess to deal with anyway.
Thank you for clarifying your position\, Andreas\, and for subsequently accepting a correction about the nature of the bans that moderators can impose.
I'm not seeking to continue "fighting over" this matter (as your subsequent message puts it)\, but I've spent the last day thinking hard about it\, and you level some specific criticisms that I'd like to respond to. There are also some aspects of my views on the wider topic of moderation that I think it would be helpful for me to set out clearly.
First and foremost\, I stand by my reading of Peter's comments as uncivil and unacceptable\, and by my decision to respond as moderator with a formal warning\, in accordance with our standards of conduct.
You describe our moderation system as one "where a single person can define that certain phrases shall be punished"\, and I read this description as a specific characterisation of my actions as moderator in this matter. I reject any contention that Peter's message required close textual analysis of individual phrases to reach a conclusion that it was uncivil; the entire tenor of it was fundamentally a personal attack.
Your point 6 seems to be suggesting that\, if any moderator replies to any message as an individual\, rather than ex officio as moderator\, that should automatically cause the message to be treated as acceptable. I disagree strongly with that: one of the reasons we have a panel of moderators is so that no one person has to take responsibility for doing all the unpleasant work of moderation. In the specific case that you raise of Sawyer replying\, I note also that there is a conflict of interest if someone bearing the brunt of a personal attack can also respond to that attack as a moderator.
You continue by saying that "there was already a chance that the discourse could go on". This suggests you consider that the motivation for having standards of conduct is merely to allow debate to continue somehow. A consequence of that position is that\, as long as *some* debate continues\, abusive and hurtful behaviour could or even should be permitted to go unchecked. Again\, I disagree fervently. I consider behaviour of this sort to be unconditionally unacceptable\, regardless of who displays it\, the context of the discussion\, and whether any other debate continues.
The more general views I want to set out hinge on the reasons why we have standards of conduct\, and moderators who attempt to ensure they're adhered to.
We hold ourselves to standards of conduct that allow us all to come to the best solutions we can\, in an environment of mutual respect and assistance. This is especially true of problems without a single obvious right answer\, and where a wide variety of options and perspectives are supported by experienced\, passionate proponents.
We hold ourselves to standards of conduct that allow us to contribute to the consideration of difficult problems without having to worry about whether we're going to bear the brunt of an unpleasant outburst.
We hold ourselves to these standards of conduct partly to make it clear to people who are not (yet) active members of our community that\, should they choose to take part\, they will be welcomed and respected\, and that they can expect to do so without having to absorb or defend themselves against hurtful comments — because *all* those who take part are defended by the structures and institutions we have put in place for that purpose.
-- Aaron Crane
p5pRT
commented
6 years ago * Leon Timmermans \fawaka@​gmail\.com [2017-12-27T23:51:27]
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
When you can boil language design down to something as simple as "Be civil\," please let us know.
We can stop people from saying unkind things\, but how are we going to prevent repeats of this utter fuck-up\, given that this "process" could have only resulted in a fuck-up?
Are we going to politely destroy perl?
This is a really bizarre post\, Leon. I don't get it.
We're going to prevent repeated errors by acknowledging when errors occur\, discussing what happened\, and trying to avoid them. Zero steps in that process require abuse.
This seems like a non-abusive post saying "this is a disaster and we need to stop and figure out what we're doing":
https://www.nntp.perl.org/group/perl.perl5.porters/2017/12/msg248329.html
Good job\, poster!
It got a reply in a day saying\, "Yes\, this is a problem\, let's undo this and think about it harder." More posts like that one\, pushing for consideration and improvement\, seem like a great idea.
-- rjbs
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 8:56 AM\, Dan Book \grinnz@​gmail\.com wrote:
I don't understand why these topics need to be conflated
Thanks for pointing out this fundamental difference in perception. It's a rather important issue\, I think it deserves a thread of its own. I promise I will come back to this.
\, and don't find that ironic whatsoever.
Civility is an essential tool towards not burning out developers\, but it's not a goal of p5p by itself. The development of the Perl language is the main goals of this list. How is it not ironic that we've forgotten how to do that?
Leon
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 3:56 PM\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org wrote:
* Leon Timmermans \fawaka@​gmail\.com [2017-12-27T23:51:27]
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
When you can boil language design down to something as simple as "Be civil\," please let us know.
We can't\, but we can at least do this much more conciously.
We can stop people from saying unkind things\, but how are we going to prevent repeats of this utter fuck-up\, given that this "process" could have only resulted in a fuck-up?
Are we going to politely destroy perl?
This is a really bizarre post\, Leon. I don't get it.
I posted in anger and I shouldn't have and I regret that. I'm sorry about that.
We're going to prevent repeated errors by acknowledging when errors occur\, discussing what happened\, and trying to avoid them.
I really don't feel like that has happened. Saying "it broke too much of CPAN so we reverted" barely touches the issue at hand here. There's no taking ownership in that.
Leon
p5pRT
commented
6 years ago * Leon Timmermans \fawaka@​gmail\.com [2017-12-28T12:25:56]
We're going to prevent repeated errors by acknowledging when errors occur\, discussing what happened\, and trying to avoid them.
I really don't feel like that has happened. Saying "it broke too much of CPAN so we reverted" barely touches the issue at hand here. There's no taking ownership in that.
I think the process started\, and (as you suggest) it needs to continue\, because (a) it isn't done and (b) it will need to happen again next time we think something went wrong.
-- rjbs
p5pRT
commented
6 years ago On 25 December 2017 at 21:08\, Dave Mitchell \davem@​iabyn\.com wrote:
On Sun\, Dec 24\, 2017 at 10:49:34PM +0100\, Peter Rabbitson wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
As someone who has been using Perl since 1992\, and who has been working on the perl core since 2001\, I utterly disagree with every part of your inflammatory and unevidenced statement above.
+1
Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
p5pRT
commented
6 years ago On 29 December 2017 at 03:56\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org wrote:
* Leon Timmermans \fawaka@​gmail\.com [2017-12-27T23:51:27]
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
When you can boil language design down to something as simple as "Be civil\," please let us know.
"Create certainties"
For example: Making a change that creates uncertainty\, by breaking historically expected behaviour of a language\, and in turn\, making the future of any given construct in perl uncertain for future releases\, is analogous to "incivility"
It should be considered like a personal attack on the existing codebases.
( I tried )
-- Kent
KENTNL - https://metacpan.org/author/KENTNL
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 2:50 PM\, Kent Fredric \kentfredric@​gmail\.com wrote:
On 29 December 2017 at 03:56\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org wrote:
* Leon Timmermans \fawaka@​gmail\.com [2017-12-27T23:51:27]
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
When you can boil language design down to something as simple as "Be civil\," please let us know.
"Create certainties"
For example: Making a change that creates uncertainty\, by breaking historically expected behaviour of a language\, and in turn\, making the future of any given construct in perl uncertain for future releases\, is analogous to "incivility"
It should be considered like a personal attack on the existing codebases.
( I tried )
That's a nice start for your personal favorite aspect\, but doesn't encompass 1/10th of what such 'policies' need to cover.
-Dan
p5pRT
commented
6 years ago On Wed\, Dec 27\, 2017 at 8:51 PM\, Leon Timmermans \fawaka@​gmail\.com wrote:
We can stop people from saying unkind things\, but how are we going to prevent repeats of this utter fuck-up\, given that this "process" could have only resulted in a fuck-up?
Are we going to politely destroy perl ?
To expand on these points a bit\, I think the process failures we had here include:
- introduction of a breaking change in syntax late in the development cycle (the cutoff for contentious changes is in less than a month\, which gives little time to resolve breakage downstream - so at this point in the cycle such breakage should be *small* and *contained*)
- changes were not apparently pushed to a smoke-me branch first\, where we could have assessed the amount of downstream breakage and then discussed what to do next (I would suggest that syntax changes *must always* be smoked first before merging to blead) - changes were not committed in a rebased branch\, which (as previously discussed) makes bisections more difficult\, and also complicates the now-inevitable reversion process
- introduction of user-facing syntax changes to a well-known-to-be-controversial feature without discussion of the proposal in the greater community (outside of just p5p) of the new keywords and their function
These are all things we should improve in our process.
respectfully\, Karen Etheridge
ether@cpan.org
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 12:56 PM\, demerphq \demerphq@​gmail\.com wrote:
On 25 December 2017 at 21:08\, Dave Mitchell \davem@​iabyn\.com wrote:
On Sun\, Dec 24\, 2017 at 10:49:34PM +0100\, Peter Rabbitson wrote:
So today\, instead of all the positive stuff above\, you are an absolute\, irredeemable failure and embarrassment as a technical leader and as a user advocate\, feverishly butchering one of the oldest mainstream languages. And for what?
As someone who has been using Perl since 1992\, and who has been working on the perl core since 2001\, I utterly disagree with every part of your inflammatory and unevidenced statement above.
+1
Yves
Me three.
p5pRT
commented
6 years ago On Thu\, Dec 28\, 2017 at 2:28 PM\, Dan Book \grinnz@​gmail\.com wrote:
On Thu\, Dec 28\, 2017 at 2:50 PM\, Kent Fredric \kentfredric@​gmail\.com wrote:
On 29 December 2017 at 03:56\, Ricardo Signes \perl\.p5p@​rjbs\.manxome\.org wrote:
* Leon Timmermans \fawaka@​gmail\.com [2017-12-27T23:51:27]
Apparently we have a process of moderation\, but no process of language design whatsoever. That's pretty damn ironic\, don't you think?
When you can boil language design down to something as simple as "Be civil\," please let us know.
"Create certainties"
For example: Making a change that creates uncertainty\, by breaking historically expected behaviour of a language\, and in turn\, making the future of any given construct in perl uncertain for future releases\, is analogous to "incivility"
It should be considered like a personal attack on the existing codebases.
I don't buy the analogy. Personal attacks can only happen to persons. We should respect the people who maintain downstream code and be very cautious about incompatible changes\, but there's no reason to mix that up with the rules of discussion on the mailing list. I would also like to point out that while civility is free\, maintaining 100% backward compatibility can be very expensive.
( I tried )
That's a nice start for your personal favorite aspect\, but doesn't encompass 1/10th of what such 'policies' need to cover.
But this isn't language design; it's change management. Which is something that *can* be partially addressed by policy\, and perhaps there are some things that should be changed or added in that regard. However\, I would caution folks from trying to generalize too much from a situation that is surely unique. I don't recall any other time in the history of Perl that a feature was considered so horribly broken by the people who had invested a lot of time in trying to fix it that it became flagged experimental several years after release. So let's sort out the current situation before we get on a legislative bandwagon and make ordinary life impossible because one exceptional thing happened.
Migrated from rt.perl.org#132594 (status was 'resolved')
Searchable as RT132594$