Skip Menu |

Subject: Carp is missing a dot
Date: Sun, 18 Dec 2011 19:55:53 -0800
To: perlbug [...] perl.org
From: Father Chrysostomos <sprout [...] cpan.org>
Download (untitled) / with headers
text/plain 2.6k
This was brought up in #96672 but needs its own ticket: $ perl -e 'die' Died at -e line 1. $ perl -MCarp -e 'croak Died' Died at -e line 1 Where did my dot go? The hard part is deciding what to do about cluck(). --- Flags: category=library severity=low --- Site configuration information for perl 5.15.5: Configured by sprout at Sun Dec 18 11:26:14 PST 2011. Summary of my perl5 (revision 5 version 15 subversion 5) configuration: Snapshot of: 5dca8ed9d28127c9f7a2e7ce5f8ba970da3608cd Platform: osname=darwin, osvers=10.5.0, archname=darwin-2level uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0: fri nov 5 23:20:39 pdt 2010; root:xnu-1504.9.17~1release_i386 i386 ' config_args='-de -Dusedevel -DDEBUGGING=-g' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O3 -g', cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' Locally applied patches: --- @INC for perl 5.15.5: /usr/local/lib/perl5/site_perl/5.15.5/darwin-2level /usr/local/lib/perl5/site_perl/5.15.5 /usr/local/lib/perl5/5.15.5/darwin-2level /usr/local/lib/perl5/5.15.5 /usr/local/lib/perl5/site_perl . --- Environment for perl 5.15.5: DYLD_LIBRARY_PATH (unset) HOME=/Users/sprout LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin PERL_BADLANG (unset) SHELL=/bin/bash
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 438b
On Sun Dec 18 19:56:10 2011, sprout wrote: Show quoted text
> This was brought up in #96672 but needs its own ticket: > > $ perl -e 'die' > Died at -e line 1. > $ perl -MCarp -e 'croak Died' > Died at -e line 1 > > Where did my dot go? > > The hard part is deciding what to do about cluck().
In commit 879b0cab8, Zefram has solved this by adding the dot to messages but leaving it off for subsequent lines of cluck() output. -- Father Chrysostomos
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 2 Feb 2012 16:41:23 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 603b
Father Chrysostomos wrote: Show quoted text
>Where did my dot go?
Added to Carp as 879b0cab8575cdc155c45c42eb82075648761936. This required changing an autodie test, in partial violation of UPSTREAM=>"cpan". autodie will need a new CPAN release with that change. (Also had to change a handful of core-only tests.) Show quoted text
>The hard part is deciding what to do about cluck().
I added the dot only to the base message, and left the stack trace unaltered. I don't see what punctuation would be appropriate at the end of every stack trace line, and I don't want to make the last line of it different from the others. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 2 Feb 2012 17:51:28 +0100
To: perlbug-comment [...] perl.org
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 383b
On Thu, Feb 2, 2012 at 5:39 PM, Father Chrysostomos via RT <perlbug-comment@perl.org> wrote: Show quoted text
> In commit 879b0cab8, Zefram has solved this by adding the dot to > messages but leaving it off for subsequent lines of cluck() output.
I'm worried this will break tests of CPAN modules that rely a little too much on the exact error (probably including at least one of my modules). Leon
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 2 Feb 2012 17:00:20 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 333b
Leon Timmermans wrote: Show quoted text
>I'm worried this will break tests of CPAN modules
There presumably will be a few. It's an easy fix for each. I think it's an acceptable level of hassle. If you object, you've got two weeks to render it contentious so that it has to be reverted. I'm holding off on CPAN release for this reason. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 2 Feb 2012 18:16:22 +0100
To: Zefram <zefram [...] fysh.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 516b
On Thu, Feb 2, 2012 at 6:00 PM, Zefram <zefram@fysh.org> wrote: Show quoted text
> There presumably will be a few.  It's an easy fix for each.  I think it's > an acceptable level of hassle.  If you object, you've got two weeks to > render it contentious so that it has to be reverted.  I'm holding off > on CPAN release for this reason.
I'm fine with updating my module, it's trivial indeed. I'm worried though that the list of modules with this issue is larger than expected. We'll see soon enough how big the issue is. Leon
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 655b
On Thu Feb 02 09:17:06 2012, LeonT wrote: Show quoted text
> On Thu, Feb 2, 2012 at 6:00 PM, Zefram <zefram@fysh.org> wrote:
> > There presumably will be a few. �It's an easy fix for each. �I think it's > > an acceptable level of hassle. �If you object, you've got two weeks to > > render it contentious so that it has to be reverted. �I'm holding off > > on CPAN release for this reason.
> > I'm fine with updating my module, it's trivial indeed. I'm worried > though that the list of modules with this issue is larger than > expected. We'll see soon enough how big the issue is.
So far, I've found needed test fixes in: autodie, Error, Log4perl and counting.
Subject: Re: [perl #106538] Carp is missing a dot
Date: Fri, 10 Feb 2012 16:01:47 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 165b
Todd Rinaldo via RT wrote: Show quoted text
>So far, I've found needed test fixes in: autodie, Error, Log4perl and counting.
Not very many, then. This is looking viable. -zefram
CC: perl5-porters [...] perl.org, hv [...] crypt.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 10:15:04 +0000
To: perlbug-followup [...] perl.org
From: hv [...] crypt.org
Download (untitled) / with headers
text/plain 1.1k
"Todd Rinaldo via RT" <perlbug-followup@perl.org> wrote: :On Thu Feb 02 09:17:06 2012, LeonT wrote: :> On Thu, Feb 2, 2012 at 6:00 PM, Zefram <zefram@fysh.org> wrote: :> > There presumably will be a few. �It's an easy fix for each. �I think it's :> > an acceptable level of hassle. �If you object, you've got two weeks to :> > render it contentious so that it has to be reverted. �I'm holding off :> > on CPAN release for this reason. :> :> I'm fine with updating my module, it's trivial indeed. I'm worried :> though that the list of modules with this issue is larger than :> expected. We'll see soon enough how big the issue is. : :So far, I've found needed test fixes in: autodie, Error, Log4perl and counting. One thing worth mentioning: along the lines of Nick's recent patch to separate two otherwise indistinguishable panics in perl core, there is actually an advantage to being able to discover from where an error message came. Maybe the presence or absence of a trailing full-stop is not the ideal way to signal provenance; but I think the general principle stands that you actually do lose something by making the two identical. Hugo
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 11:40:50 +0100
To: Zefram <zefram [...] fysh.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 346b
On 02/10/2012 05:01 PM, Zefram wrote: Show quoted text
> Todd Rinaldo via RT wrote:
>> So far, I've found needed test fixes in: autodie, Error, Log4perl and counting.
> > Not very many, then. This is looking viable.
If somebody supplies me with two commits to run a CPAN smoke for, then I can do that within a few days to get a more complete list. --Steffen
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 10:42:29 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 290b
Steffen Mueller wrote: Show quoted text
>If somebody supplies me with two commits to run a CPAN smoke for, >then I can do that within a few days to get a more complete list.
Obvious choice is 62e90759156bee3f2bcbf1ac6fd055aeab81b9e4 (before) and 879b0cab8575cdc155c45c42eb82075648761936 (after). -zefram
CC: perlbug-followup [...] perl.org, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 12:28:21 +0100
To: hv [...] crypt.org
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 1.6k
On 11 February 2012 11:15, <hv@crypt.org> wrote: Show quoted text
> "Todd Rinaldo via RT" <perlbug-followup@perl.org> wrote: > :On Thu Feb 02 09:17:06 2012, LeonT wrote: > :> On Thu, Feb 2, 2012 at 6:00 PM, Zefram <zefram@fysh.org> wrote: > :> > There presumably will be a few. �It's an easy fix for each. �I think it's > :> > an acceptable level of hassle. �If you object, you've got two weeks to > :> > render it contentious so that it has to be reverted. �I'm holding off > :> > on CPAN release for this reason. > :> > :> I'm fine with updating my module, it's trivial indeed. I'm worried > :> though that the list of modules with this issue is larger than > :> expected. We'll see soon enough how big the issue is. > : > :So far, I've found needed test fixes in: autodie, Error, Log4perl and counting. > > One thing worth mentioning: along the lines of Nick's recent patch to > separate two otherwise indistinguishable panics in perl core, there is > actually an advantage to being able to discover from where an error > message came. > > Maybe the presence or absence of a trailing full-stop is not the ideal > way to signal provenance; but I think the general principle stands that > you actually do lose something by making the two identical.
I agree. I'm pretty sure at least one port of perl adds error codes to all the error messages we provide. I have always thought that that is a very useful thing. Especially when messages are localized, or whatever. Id like to see a unique error code added to every error and warning generating line of code in the core, and if I thought it would be approved I'd do the work to make it happen. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 14:30:27 +0100
To: Zefram <zefram [...] fysh.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 487b
On 02/11/2012 11:42 AM, Zefram wrote: Show quoted text
> Steffen Mueller wrote:
>> If somebody supplies me with two commits to run a CPAN smoke for, >> then I can do that within a few days to get a more complete list.
> > Obvious choice is 62e90759156bee3f2bcbf1ac6fd055aeab81b9e4 (before) > and 879b0cab8575cdc155c45c42eb82075648761936 (after).
Running at http://users.perl5.git.perl.org/~tsee/progress.html Result to be at http://users.perl5.git.perl.org/~tsee/carp_errmsg/ Best regards, Steffen
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 11 Feb 2012 11:02:19 -0600
To: Steffen Mueller <smueller [...] cpan.org>
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 897b
On Sat, Feb 11, 2012 at 7:30 AM, Steffen Mueller <smueller@cpan.org> wrote: Show quoted text
> On 02/11/2012 11:42 AM, Zefram wrote:
>> >> Steffen Mueller wrote:
>>> >>> If somebody supplies me with two commits to run a CPAN smoke for, >>> then I can do that within a few days to get a more complete list.
>> >> >> Obvious choice is 62e90759156bee3f2bcbf1ac6fd055aeab81b9e4 (before) >> and 879b0cab8575cdc155c45c42eb82075648761936 (after).
> > > Running at > > http://users.perl5.git.perl.org/~tsee/progress.html > > Result to be at > > http://users.perl5.git.perl.org/~tsee/carp_errmsg/
Excellent. Muchas gracias! Problem was that maintainers often did not have blead and there is no Carp-1.25 in CPAN yet, so it was not easy to detect or reproduce. We provided patches for all but Sub-Uplevel-0.22 I think DAGOLDEN can handle it by himself. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
Subject: Re: [perl #106538] Carp is missing a dot
Date: Mon, 13 Feb 2012 10:36:42 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 802b
* demerphq <demerphq@gmail.com> [2012-02-11T06:28:21] Show quoted text
> I agree. I'm pretty sure at least one port of perl adds error codes to > all the error messages we provide. I have always thought that that is > a very useful thing. Especially when messages are localized, or > whatever. Id like to see a unique error code added to every error and > warning generating line of code in the core, and if I thought it would > be approved I'd do the work to make it happen.
This is something I'd hoped to see quite a while ago, as part of a "exceptions are objects" update. I'd like to pursue this, for sure, but am probably not going to give it a front burner in my brain until 5.17. I will save and review all proposals on it, though! We had talked about giving exceptions tags as well, at the time. -- rjbs
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 11:42:56 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 256b
Steffen Mueller wrote: Show quoted text
Not yet complete, but now showing 28 distros that passed before and fail after and 20 that changed behaviour in some other way. Anyone want to argue that it's too many? -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 10:53:03 -0600
To: Zefram <zefram [...] fysh.org>
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 845b
On Wed, Feb 15, 2012 at 5:42 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Steffen Mueller wrote: > > Not yet complete, but now showing 28 distros that passed before and fail > after and 20 that changed behaviour in some other way.  Anyone want to > argue that it's too many?
This made a lot of people angry, not only people who had their CPAN modules changed for purley aesthetic consistency reasons. Carp's only API is the string return value. Additionally carp is with die our primary exception mechanism. Changing the API would have required an API bump, like Carp2 or use Carp (-dot). But that is already over, so I'm content with that change. It was only a night of work to get CPAN fixed and all authors took the fixes. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 17:07:15 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 983b
Reini Urban wrote: Show quoted text
>This made a lot of people angry,
Anything you can point at? Blogs? Show quoted text
>But that is already over, so I'm content with that change.
It's not a done deal. The dot change only exists in blead. I've deliberately held off from making a CPAN release until we've made a decision on whether we actually want it. The smoke tests that we get from having it in blead are an important input to that decision. In five days we'll have a 5.15.8 release, and whatever version of Carp it has will also go to CPAN. If the dot remains in, that's when it becomes widely visible. If we want the dot out, best to take it out before then. That's why I'm asking now. If we leave it in at 5.15.8 and decide later that we need it out for 5.16, we can do that, but it's messier. Show quoted text
>It was only a night of work to get CPAN fixed and all authors took the fixes.
By "CPAN" do you mean "all of the affected modules on CPAN"? I believe we don't have a final tally of them yet. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 11:27:01 -0600
To: Zefram <zefram [...] fysh.org>
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Reini Urban wrote:
>>This made a lot of people angry,
> > Anything you can point at?  Blogs?
Not publicly. Normal people do not blog or complain upstream at the interior ministry. Ask around. Show quoted text
>>But that is already over, so I'm content with that change.
> > It's not a done deal.  The dot change only exists in blead.  I've > deliberately held off from making a CPAN release until we've made a > decision on whether we actually want it.  The smoke tests that we get > from having it in blead are an important input to that decision. > > In five days we'll have a 5.15.8 release, and whatever version of Carp it > has will also go to CPAN.  If the dot remains in, that's when it becomes > widely visible.  If we want the dot out, best to take it out before then. > That's why I'm asking now.  If we leave it in at 5.15.8 and decide later > that we need it out for 5.16, we can do that, but it's messier. >
>>It was only a night of work to get CPAN fixed and all authors took the fixes.
> > By "CPAN" do you mean "all of the affected modules on CPAN"?  I believe > we don't have a final tally of them yet.
"All of CPAN" we use, that is 652 of 29916 packages. The most common fraction. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 11:36:43 -0600
To: Reini Urban <rurban [...] x-ray.at>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 550b
On Wed, Feb 15, 2012 at 11:27:01AM -0600, Reini Urban wrote: Show quoted text
> On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote:
> > Reini Urban wrote:
> >>This made a lot of people angry,
> > > > Anything you can point at?  Blogs?
> > Not publicly. Normal people do not blog or complain > upstream at the interior ministry. Ask around.
So how are we to know that they exist? We can't really go around asking every Perl user about every change that we make to core, and we can't just stop making changes to core. What is the solution here? -doy
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 12:38:39 -0600
To: Jesse Luehrs <doy [...] tozt.net>
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 814b
On Wed, Feb 15, 2012 at 11:36 AM, Jesse Luehrs <doy@tozt.net> wrote: Show quoted text
> On Wed, Feb 15, 2012 at 11:27:01AM -0600, Reini Urban wrote:
>> On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote:
>> > Reini Urban wrote:
>> >>This made a lot of people angry,
>> > >> > Anything you can point at?  Blogs?
>> >> Not publicly. Normal people do not blog or complain >> upstream at the interior ministry. Ask around.
> > So how are we to know that they exist? We can't really go around asking > every Perl user about every change that we make to core, and we can't > just stop making changes to core. What is the solution here?
Make the right decisions. Don't upset people too much. use common sense. yes, marc lehman is right most of the time -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 12:40:29 -0600
To: Reini Urban <rurban [...] x-ray.at>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 784b
On Wed, Feb 15, 2012 at 12:38:39PM -0600, Reini Urban wrote: Show quoted text
> On Wed, Feb 15, 2012 at 11:36 AM, Jesse Luehrs <doy@tozt.net> wrote:
> > On Wed, Feb 15, 2012 at 11:27:01AM -0600, Reini Urban wrote:
> >> On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote:
> >> > Reini Urban wrote:
> >> >>This made a lot of people angry,
> >> > > >> > Anything you can point at?  Blogs?
> >> > >> Not publicly. Normal people do not blog or complain > >> upstream at the interior ministry. Ask around.
> > > > So how are we to know that they exist? We can't really go around asking > > every Perl user about every change that we make to core, and we can't > > just stop making changes to core. What is the solution here?
> > Make the right decisions.
Oh, is it really that easy? -doy
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 12:42:02 -0600
To: Jesse Luehrs <doy [...] tozt.net>
From: Reini Urban <rurban [...] x-ray.at>
On Wed, Feb 15, 2012 at 12:40 PM, Jesse Luehrs <doy@tozt.net> wrote: Show quoted text
> On Wed, Feb 15, 2012 at 12:38:39PM -0600, Reini Urban wrote:
>> On Wed, Feb 15, 2012 at 11:36 AM, Jesse Luehrs <doy@tozt.net> wrote:
>> > On Wed, Feb 15, 2012 at 11:27:01AM -0600, Reini Urban wrote:
>> >> On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote:
>> >> > Reini Urban wrote:
>> >> >>This made a lot of people angry,
>> >> > >> >> > Anything you can point at?  Blogs?
>> >> >> >> Not publicly. Normal people do not blog or complain >> >> upstream at the interior ministry. Ask around.
>> > >> > So how are we to know that they exist? We can't really go around asking >> > every Perl user about every change that we make to core, and we can't >> > just stop making changes to core. What is the solution here?
>> >> Make the right decisions.
> > Oh, is it really that easy?
Sorry, I forgot: marketing. Persuade people why they must change their code. Before people like me jump on them on other more-general aspects. -- Reini Urban http://cpanel.net/   http://www.perl-compiler.org/
CC: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 12:51:40 -0600
To: Reini Urban <rurban [...] x-ray.at>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Feb 15, 2012 at 12:42:02PM -0600, Reini Urban wrote: Show quoted text
> On Wed, Feb 15, 2012 at 12:40 PM, Jesse Luehrs <doy@tozt.net> wrote:
> > On Wed, Feb 15, 2012 at 12:38:39PM -0600, Reini Urban wrote:
> >> On Wed, Feb 15, 2012 at 11:36 AM, Jesse Luehrs <doy@tozt.net> wrote:
> >> > On Wed, Feb 15, 2012 at 11:27:01AM -0600, Reini Urban wrote:
> >> >> On Wed, Feb 15, 2012 at 11:07 AM, Zefram <zefram@fysh.org> wrote:
> >> >> > Reini Urban wrote:
> >> >> >>This made a lot of people angry,
> >> >> > > >> >> > Anything you can point at?  Blogs?
> >> >> > >> >> Not publicly. Normal people do not blog or complain > >> >> upstream at the interior ministry. Ask around.
> >> > > >> > So how are we to know that they exist? We can't really go around asking > >> > every Perl user about every change that we make to core, and we can't > >> > just stop making changes to core. What is the solution here?
> >> > >> Make the right decisions.
> > > > Oh, is it really that easy?
> > Sorry, I forgot: marketing. > > Persuade people why they must change their code. > Before people like me jump on them on other more-general aspects.
Which people? The only method of communication we have with the majority of Perl users is through deprecation warnings. -doy
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 15 Feb 2012 20:03:52 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
* Zefram <zefram@fysh.org> [2012-02-15T06:42:56] Show quoted text
> Steffen Mueller wrote: > > Not yet complete, but now showing 28 distros that passed before and fail > after and 20 that changed behaviour in some other way. Anyone want to > argue that it's too many?
It's a bummer that, if released, this will be the second change to this behavior. I hope nobody will be too put out having to fix tests a second time. I think this should be corrected. Hopefully the next changes we have to make on this front will be "replace the stack and exception mechanism with something was awesomer" and not "add a missing dot!" I had a quick glance over the smoke changes looking for core modules and the only one that leaped out at me was autodie; presumably we can fix that in core if we can't get Paul to issue a new version immediately. Reini suggested on IRC, today, that he had already been in touch with all the affected authors. Has this really been done? That would be great! -- rjbs
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 16 Feb 2012 07:53:50 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 1.5k
On 02/16/2012 02:03 AM, Ricardo Signes wrote: Show quoted text
> * Zefram<zefram@fysh.org> [2012-02-15T06:42:56]
>> Steffen Mueller wrote: >> >> Not yet complete, but now showing 28 distros that passed before and fail >> after and 20 that changed behaviour in some other way. Anyone want to >> argue that it's too many?
> > It's a bummer that, if released, this will be the second change to this > behavior. I hope nobody will be too put out having to fix tests a second time. > > I think this should be corrected. Hopefully the next changes we have to make > on this front will be "replace the stack and exception mechanism with something > was awesomer" and not "add a missing dot!" > > I had a quick glance over the smoke changes looking for core modules and the > only one that leaped out at me was autodie; presumably we can fix that in core > if we can't get Paul to issue a new version immediately. > > Reini suggested on IRC, today, that he had already been in touch with all the > affected authors. Has this really been done? That would be great!
Now up to ~30-35 degradations. Reini qualified his statement as "the authors of all modules that we [presumably cPanel] use" which was on the order of 600-700 out of tens of thousands modules on the CPAN. Since authors of infrequently used modules are as likely to hard-core error messages, I'd say that this is not yet a done deal. I expect that at least a handful of the modules would require taking over to make a new release or else they're dead wood. --Steffen
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 16 Feb 2012 10:16:06 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 410b
Ricardo Signes wrote: Show quoted text
>I had a quick glance over the smoke changes looking for core modules and the >only one that leaped out at me was autodie; presumably we can fix that in core
My commit to modify Carp did edit the autodie test in core. But not in the correct way for the CPAN version: I changed it to *require* the dot, which is OK in core, but the CPAN version needs to make the dot optional. -zefram
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 16 Feb 2012 09:23:11 -0600
To: Steffen Mueller <smueller [...] cpan.org>
From: Reini Urban <ru [...] x-ray.at>
Am 16.02.2012 um 00:53 schrieb Steffen Mueller: Show quoted text
> On 02/16/2012 02:03 AM, Ricardo Signes wrote:
>> * Zefram<zefram@fysh.org> [2012-02-15T06:42:56]
>>> Steffen Mueller wrote: >>> >>> Not yet complete, but now showing 28 distros that passed before and fail >>> after and 20 that changed behaviour in some other way. Anyone want to >>> argue that it's too many?
>> >> It's a bummer that, if released, this will be the second change to this >> behavior. I hope nobody will be too put out having to fix tests a second time. >> >> I think this should be corrected. Hopefully the next changes we have to make >> on this front will be "replace the stack and exception mechanism with something >> was awesomer" and not "add a missing dot!" >> >> I had a quick glance over the smoke changes looking for core modules and the >> only one that leaped out at me was autodie; presumably we can fix that in core >> if we can't get Paul to issue a new version immediately. >> >> Reini suggested on IRC, today, that he had already been in touch with all the >> affected authors. Has this really been done? That would be great!
Me and toddr checked the 600-700 modules we package as rpm and filed bugreports with patches. I guess for Carp it was about 4-5, for defined(@%) it was more. Todd has the numbers and ticket id's. Sub::UpLevel, log4perl and Test::Warn being the most important. All them were accepted resp. fixed in a better way, but the authors wait until this new Carp 1.25 is actually released. I did the check with a $Carp::VERSION compare. Show quoted text
> Now up to ~30-35 degradations. Reini qualified his statement as "the authors of all modules that we [presumably cPanel] use" which was on the order of 600-700 out of tens of thousands modules on the CPAN. Since authors of infrequently used modules are as likely to hard-core error messages, I'd say that this is not yet a done deal. > > I expect that at least a handful of the modules would require taking over to make a new release or else they're dead wood.
Yes, thanks for your full test.
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 16 Feb 2012 15:28:57 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 220b
Reini Urban wrote: Show quoted text
>I did the check with a $Carp::VERSION compare.
That's not a great idea. Better to just accept messages with or without the dot. You don't need to know which version of Carp you're using. -zefram
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 16 Feb 2012 14:35:13 -0600
To: Zefram <zefram [...] fysh.org>
From: Reini Urban <rurban [...] x-ray.at>
Download (untitled) / with headers
text/plain 456b
On Thu, Feb 16, 2012 at 9:28 AM, Zefram <zefram@fysh.org> wrote: Show quoted text
> Reini Urban wrote:
>>I did the check with a $Carp::VERSION compare.
> > That's not a great idea.  Better to just accept messages with or without > the dot.  You don't need to know which version of Carp you're using.
Sure. I didn't know that time that it will be changed again. Currently Log4perl and Test::Warn will have to be fixed again, no big deal. Test::Warn is bummer. -- Reini
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sat, 18 Feb 2012 14:31:56 +0100
To: Reini Urban <ru [...] x-ray.at>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 365b
On 02/16/2012 04:23 PM, Reini Urban wrote: Show quoted text
> Yes, thanks for your full test.
That's done now. Do note the high number of distributions that could not be tested on the patched perl: This is because they depend on one of the distributions that failed tests. So in theory, once those are fixed, we'd have to run the smoke again to get a full coverage. --Steffen
CC: Reini Urban <ru [...] x-ray.at>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sun, 26 Feb 2012 17:41:54 +0100
To: Steffen Mueller <smueller [...] cpan.org>
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 564b
Show quoted text
>>>>> On Sat, 18 Feb 2012 14:31:56 +0100, Steffen Mueller <smueller@cpan.org> said:
Show quoted text
> On 02/16/2012 04:23 PM, Reini Urban wrote:
>> Yes, thanks for your full test.
Show quoted text
> That's done now. Do note the high number of distributions that could > not be tested on the patched perl: This is because they depend on one > of the distributions that failed tests. So in theory, once those are > fixed, we'd have to run the smoke again to get a full coverage.
Maybe now's the time. If you can, please install CHORNY/Test-Warn-0.23_01.tar.gz and rerun. -- andreas
CC: Reini Urban <ru [...] x-ray.at>, Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Sun, 26 Feb 2012 20:03:38 +0100
To: "Andreas J. Koenig" <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 739b
On 02/26/2012 05:41 PM, Andreas J. Koenig wrote: Show quoted text
>>>>>> On Sat, 18 Feb 2012 14:31:56 +0100, Steffen Mueller<smueller@cpan.org> said:
>
> > On 02/16/2012 04:23 PM, Reini Urban wrote:
> >> Yes, thanks for your full test.
>
> > That's done now. Do note the high number of distributions that could > > not be tested on the patched perl: This is because they depend on one > > of the distributions that failed tests. So in theory, once those are > > fixed, we'd have to run the smoke again to get a full coverage.
> > Maybe now's the time. If you can, please install > CHORNY/Test-Warn-0.23_01.tar.gz and rerun.
Should be running with an updated CPAN mirror (so expect some other differences). Best regards, Steffen
Subject: Re: [perl #106538] Carp is missing a dot
Date: Tue, 28 Feb 2012 21:21:59 +0100
To: perl5-porters [...] perl.org
From: Alexander Hartmaier <alex.hartmaier [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
I was one of the upset people Reini talked about.
If a new Perl version brings such a change noted in its changelog thats fine, releasing a new version of a dual-lifed module to CPAN without a fat warning in the changelog isn't.

The reason(s) why such an unimportant looking but fail introducting change was made would also be welcome.

-Alex (abraxxa)


On Sun, Feb 26, 2012 at 8:03 PM, Steffen Mueller <smueller@cpan.org> wrote:
Show quoted text
On 02/26/2012 05:41 PM, Andreas J. Koenig wrote:
On Sat, 18 Feb 2012 14:31:56 +0100, Steffen Mueller<smueller@cpan.org>  said:

  >  On 02/16/2012 04:23 PM, Reini Urban wrote:
 >>  Yes, thanks for your full test.

  >  That's done now. Do note the high number of distributions that could
  >  not be tested on the patched perl: This is because they depend on one
  >  of the distributions that failed tests. So in theory, once those are
  >  fixed, we'd have to run the smoke again to get a full coverage.

Maybe now's the time. If you can, please install
CHORNY/Test-Warn-0.23_01.tar. gz and rerun.

Should be running with an updated CPAN mirror (so expect some other differences).

Best regards,
Steffen

CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Tue, 28 Feb 2012 20:19:57 -0500
To: Alexander Hartmaier <alex.hartmaier [...] gmail.com>
From: Chris Prather <chris [...] prather.org>
Download (untitled) / with headers
text/plain 1.3k
On Tue, Feb 28, 2012 at 3:21 PM, Alexander Hartmaier <alex.hartmaier@gmail.com> wrote: Show quoted text
> I was one of the upset people Reini talked about. > If a new Perl version brings such a change noted in its changelog thats > fine, releasing a new version of a dual-lifed module to CPAN without a fat > warning in the changelog isn't. > > The reason(s) why such an unimportant looking but fail introducting change > was made would also be welcome.
Having consistent things be consistent is a nice feature. The change log for Carp does include mention of this change. At the time of the release no more than 35 modules out of >14K tested were showing any possible change due to this patch, it seems reasonable that a simple mention was all that was expected to be required. No-one (including Reini) pointed out more than a fraction of a percentage of affected modules in the two weeks between when the patch was made and the development release of Perl that this dual-lifed module was bundled with was released. (Or if they did it is not recorded in this thread). Reini only brought up that a group of unnamed people such as yourself had issues with this change the day before the release. The nice part about the development process for Perl5 is that any interested parties, such as yourself, can participate to make sure that your concerns are noted and dealt with *before* a release happens. -Chris
CC: Alexander Hartmaier <alex.hartmaier [...] gmail.com>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 07:56:32 +0100
To: Chris Prather <chris [...] prather.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 1.7k
On 02/29/2012 02:19 AM, Chris Prather wrote: Show quoted text
> On Tue, Feb 28, 2012 at 3:21 PM, Alexander Hartmaier > <alex.hartmaier@gmail.com> wrote:
>> I was one of the upset people Reini talked about. >> If a new Perl version brings such a change noted in its changelog thats >> fine, releasing a new version of a dual-lifed module to CPAN without a fat >> warning in the changelog isn't. >> >> The reason(s) why such an unimportant looking but fail introducting change >> was made would also be welcome.
> > Having consistent things be consistent is a nice feature. > > The change log for Carp does include mention of this change. At the > time of the release no more than 35 modules out of>14K tested were > showing any possible change due to this patch, it seems reasonable > that a simple mention was all that was expected to be required. > > No-one (including Reini) pointed out more than a fraction of a > percentage of affected modules in the two weeks between when the patch > was made and the development release of Perl that this dual-lifed > module was bundled with was released. (Or if they did it is not > recorded in this thread). Reini only brought up that a group of > unnamed people such as yourself had issues with this change the day > before the release. > > The nice part about the development process for Perl5 is that any > interested parties, such as yourself, can participate to make sure > that your concerns are noted and dealt with *before* a release > happens.
The CPAN smoke did show, though, that there are a few distributions that break and ripple to a good fraction of the CPAN. Fixing Test::Warn has done away with a good chunk of that, but let's wait for the resmoke at: http://users.perl5.git.perl.org/~tsee/progress.html http://users.perl5.git.perl.org/~tsee/carp_errmsg/ --Steffen
CC: Alexander Hartmaier <alex.hartmaier [...] gmail.com>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 08:18:50 +0100
To: Chris Prather <chris [...] prather.org>
From: andreas.koenig.7os6VVqR [...] franz.ak.mind.de (Andreas J. Koenig)
Download (untitled) / with headers
text/plain 1.7k
Show quoted text
>>>>> On Tue, 28 Feb 2012 20:19:57 -0500, Chris Prather <chris@prather.org> said:
Show quoted text
> The change log for Carp does include mention of this change. At the > time of the release no more than 35 modules out of >14K tested were > showing any possible change due to this patch, it seems reasonable > that a simple mention was all that was expected to be required.
Nope. I'd say we blew it major way. Changing such a heavily used module in a rush a few days before freeze is not as excusable as you put it. Such a relatively irrelevant change should have been postponed to the early phases of the next release cycle. It was put into blead trunk. Instead of a smoke-me branch. And Steffen's parallel smoke setup should have been involved *before* a merge into blead trunk was even considered. Show quoted text
> No-one (including Reini) pointed out more than a fraction of a > percentage of affected modules in the two weeks between when the patch > was made and the development release of Perl that this dual-lifed > module was bundled with was released.
Sub::Uplevel was effected and reported. Since it is part of the toolchain it broke the smoke process for *everything* for a few days. Show quoted text
> (Or if they did it is not recorded in this thread). Reini only > brought up that a group of unnamed people such as yourself had > issues with this change the day before the release.
Show quoted text
> The nice part about the development process for Perl5 is that any > interested parties, such as yourself, can participate to make sure > that your concerns are noted and dealt with *before* a release > happens.
A cheap excuse. We should stand to our mistakes. Development should slow down in February and such changes should not be tried out in the trunk ever. Let's put this into our book of mistakes that should not have happened. -- andreas
CC: Chris Prather <chris [...] prather.org>, Alexander Hartmaier <alex.hartmaier [...] gmail.com>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 09:17:05 +0100
To: "Andreas J. Koenig" <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 3.1k
On 29 February 2012 08:18, Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote: Show quoted text
>>>>>> On Tue, 28 Feb 2012 20:19:57 -0500, Chris Prather <chris@prather.org> said:
> >  > The change log for Carp does include mention of this change. At the >  > time of the release no more than 35 modules out of >14K tested were >  > showing any possible change due to this patch, it seems reasonable >  > that a simple mention was all that was expected to be required. > > Nope. I'd say we blew it major way. > > Changing such a heavily used module in a rush a few days before freeze > is not as excusable as you put it. Such a relatively irrelevant change > should have been postponed to the early phases of the next release > cycle. It was put into blead trunk. Instead of a smoke-me branch. And > Steffen's parallel smoke setup should have been involved *before* a > merge into blead trunk was even considered. > >  > No-one (including Reini) pointed out more than a fraction of a >  > percentage of affected modules in the two weeks between when the patch >  > was made and the development release of Perl that this dual-lifed >  > module was bundled with was released. > > Sub::Uplevel was effected and reported. Since it is part of the > toolchain it broke the smoke process for *everything* for a few days. > >  > (Or if they did it is not recorded in this thread). Reini only >  > brought up that a group of unnamed people such as yourself had >  > issues with this change the day before the release. > >  > The nice part about the development process for Perl5 is that any >  > interested parties, such as yourself, can participate to make sure >  > that your concerns are noted and dealt with *before* a release >  > happens. > > A cheap excuse. We should stand to our mistakes. Development should slow > down in February and such changes should not be tried out in the trunk > ever. Let's put this into our book of mistakes that should not have > happened.
I think you have somewhat of a point, especially as regards timing. However I think the counterpoint is that people should not be testing raw output from core modules in the way that caused problems. We make no commitments as to a particular output format in Carp, so hard testing a snapshot of its output is unwise. In git terms Carp is not plumbing, it is porcelain, so establishing hard dependencies on how it works is an unforced error by the module author, not by the people changing Carp. Let me put this another way, almost for sure these errors come down to someone snapshotting the output of Carp. The authors who did this were too lazy to write their test to be robust to possible changes in Carp, For instance, they could have checked to see if a fragment of the carp output that was relevant to them. Instead they established a hard dependency on something that has no API guarantees, and it cost them. That is not Perls fault. It is much the same as using a private internals routine and then getting upset when it is removed. On the other hand, we knew that this was going to cause turbulence and should have been more proactive in addressing it before the fact. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 05:32:57 -0500
To: "Andreas J. Koenig" <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Alexander Hartmaier <alex.hartmaier [...] gmail.com>
From: Chris Prather <chris [...] prather.org>
Download (untitled) / with headers
text/plain 5.9k
On Wed, Feb 29, 2012 at 2:18 AM, Andreas J. Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote: Show quoted text
>>>>>> On Tue, 28 Feb 2012 20:19:57 -0500, Chris Prather <chris@prather.org> said:
> >  > The change log for Carp does include mention of this change. At the >  > time of the release no more than 35 modules out of >14K tested were >  > showing any possible change due to this patch, it seems reasonable >  > that a simple mention was all that was expected to be required. > > Nope. I'd say we blew it major way.
I'm not arguing that we didn't. Hindsight is a wonderfully clarifying lens. Show quoted text
> Changing such a heavily used module in a rush a few days before freeze > is not as excusable as you put it. Such a relatively irrelevant change > should have been postponed to the early phases of the next release > cycle. It was put into blead trunk. Instead of a smoke-me branch. And > Steffen's parallel smoke setup should have been involved *before* a > merge into blead trunk was even considered.
Your definition of "in a rush" and "a few days" differs from mine. Even then I'm not sure it is fair, or accurate, to blame the outcome on a last-minute-rush-job. You first reported a bug (in what is apparently an important piece of the toolchain) within two days of the patch landing on blead. Two weeks should have been more than enough time to triage this enough to at least back it out. Obviously (to be very American for a moment) mistakes were made. Show quoted text
>  > No-one (including Reini) pointed out more than a fraction of a >  > percentage of affected modules in the two weeks between when the patch >  > was made and the development release of Perl that this dual-lifed >  > module was bundled with was released. > > Sub::Uplevel was effected and reported. Since it is part of the > toolchain it broke the smoke process for *everything* for a few days.
See that's useful to know. I know you put a great deal of effort into smoking and reporting errors. I've been the recipient of this service myself, and I'm grateful for it. I see that you filed a perlbug on on 2012-02-04, and are cited in the Changes for Sub::Uplevel on 2012-02-07. However from the context in this thread it seems that Zefram didn't know about this as of the 10th when the only modules mentioned explicitly as broken so far were autodie, error, and Log4perl; or if he did know he didn't recognize the significance. Show quoted text
>  > (Or if they did it is not recorded in this thread). Reini only >  > brought up that a group of unnamed people such as yourself had >  > issues with this change the day before the release. > >  > The nice part about the development process for Perl5 is that any >  > interested parties, such as yourself, can participate to make sure >  > that your concerns are noted and dealt with *before* a release >  > happens. > > A cheap excuse. We should stand to our mistakes. Development should slow > down in February and such changes should not be tried out in the trunk > ever. Let's put this into our book of mistakes that should not have > happened.
It wasn't intended to be an excuse, cheap or otherwise. One of the best parts about OpenSource is that people are free to participate at any stage in the process. I did let my annoyance show through in the phrasing though, and I apologize to abraxxa for my tone, it wasn't helpful or necessary. I agree with you there were mistakes. I'm not sure they were obviously avoidable. What can we do to make sure they don't happen again? You have suggested that any contentious change be put it into a smoke-me branch. I agree. The problem was that this change wasn't seen as being contentious. You're free to argue if it should have been or not, but I am certain that sometime we will face a situation again where a seemingly trivial change causes unforeseen trauma. The fact that the change is seemingly trivial means you won't know ahead of time that it should be in a smoke-me branch. Should then *all* changes go through a smoke-me change? I treat all of my patches to important multi-person projects this way and do all of my work in topic branch and then get someone else to review it. The downside to this is that things don't always get merged before they've bit-rotted. Also smoking a branch for downstream changes is a multi-day process (as I'm sure you're aware). I'm not sure this is the optimal solution. Maybe this should be part of the 'Contentious changes freeze' process? It is certainly part of the 'User-visible changes freeze', so maybe the dates for the various freezes need to be adjusted? We can also clarify better what commits should be automatically put into a smoke-me branch regardless of how trivial they may seem regardless of the current slushiness of blead. If someone can point me in the direction of the proper documentation to patch I'm willing to make sure it is properly recorded. Obviously the issue for this change *was* known within the two week window Zefram had for rolling back the change. You filed a perlbug for it two day later. Why wasn't this perlbug noticed sometime before the 2012-02-16 when Zefram made the dual-life release? I'm going to guess that the parties interested in failures for the Carp change (obviously) didn't see the perlbug because they were busy. I'm also going to guess that you didn't see this thread asking for failures for the same reason. This is a volunteer process so people have to be allowed to be busy. Is there some way we can make these things more noticeable? I didn't realize that Sub::Uplevel was such a core part of the toolchain. It's not part of core, so I can understand why Zefram didn't test it when he made his initial patch. Obviously you noticed the Sub::Uplevel change within 2 days of the patch landing in blead. Was this serendipity or were you working in this specific area? I would love to have a list of non-core toolchain modules to Task::Kensho::Toolchain. This could then provide perhaps a quicker turn-around smoke for the important bits of the toolchain first. Is there anything else that can be done to help prevent this class of mistakes from cropping up? -Chris
CC: "Andreas J. Koenig" <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Alexander Hartmaier <alex.hartmaier [...] gmail.com>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 10:57:46 +0000
To: Chris Prather <chris [...] prather.org>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 3.4k
[ignoring all other details, one point below] On Wed, Feb 29, 2012 at 05:32:57AM -0500, Chris Prather wrote: Show quoted text
> On Wed, Feb 29, 2012 at 2:18 AM, Andreas J. Koenig > <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
> >>>>>> On Tue, 28 Feb 2012 20:19:57 -0500, Chris Prather <chris@prather.org> said:
> > > >  > The change log for Carp does include mention of this change. At the > >  > time of the release no more than 35 modules out of >14K tested were > >  > showing any possible change due to this patch, it seems reasonable > >  > that a simple mention was all that was expected to be required. > > > > Nope. I'd say we blew it major way.
> > I'm not arguing that we didn't. Hindsight is a wonderfully clarifying lens. >
> > Changing such a heavily used module in a rush a few days before freeze > > is not as excusable as you put it. Such a relatively irrelevant change > > should have been postponed to the early phases of the next release > > cycle. It was put into blead trunk. Instead of a smoke-me branch. And > > Steffen's parallel smoke setup should have been involved *before* a > > merge into blead trunk was even considered.
Show quoted text
> You have suggested that any contentious change be put it into a > smoke-me branch. I agree. The problem was that this change wasn't seen > as being contentious. You're free to argue if it should have been or > not, but I am certain that sometime we will face a situation again > where a seemingly trivial change causes unforeseen trauma. The fact > that the change is seemingly trivial means you won't know ahead of > time that it should be in a smoke-me branch.
Putting it in a smoke-me branch would not have helped. That tests building the core with different configurations on different platforms. All tests passed for all core modules. That's all it can tell. The thing that *would* have got it is a "build all of CPAN", which we don't have the resources to do for every change. So it gets down to - how do we spot which changes need that sort of thing? Show quoted text
> Should then *all* changes go through a smoke-me change? I treat all of
I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't have caught this one. (We'd need to improve the smoke-me reporting infrastructure to make this useful though) Show quoted text
> I didn't realize that Sub::Uplevel was such a core part of the > toolchain. It's not part of core, so I can understand why Zefram > didn't test it when he made his initial patch. Obviously you noticed > the Sub::Uplevel change within 2 days of the patch landing in blead. > Was this serendipity or were you working in this specific area? I > would love to have a list of non-core toolchain modules to > Task::Kensho::Toolchain. This could then provide perhaps a quicker > turn-around smoke for the important bits of the toolchain first.
Right. What *is* the toolchain? I was under the impression that the core shipped pretty much all of the toolchain. (Although, thanks to configure_requires support now being widespread, you shouldn't actually notice if it doesn't.) Show quoted text
> Is there anything else that can be done to help prevent this class of > mistakes from cropping up?
I think the key thing that was missing here was realising that this change broke the CPAN smokers *reporting* setup. Which would have cut off reports, and hence hidden the problems. Regular automated smoke testing to be sure that the reporting setup isn't broken seems like the first thing to fix. Unlike "all of CPAN", doing that on a fast cycle seems tractable. Nicholas Clark
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 06:11:49 -0500
To: Nicholas Clark <nick [...] ccl4.org>
From: Chris Prather <chris [...] prather.org>
Download (untitled) / with headers
text/plain 1.9k
On Wed, Feb 29, 2012 at 5:57 AM, Nicholas Clark <nick@ccl4.org> wrote: Show quoted text
> [ignoring all other details, one point below]
[ditto] Show quoted text
> Putting it in a smoke-me branch would not have helped. That tests building > the core with different configurations on different platforms. > > All tests passed for all core modules. That's all it can tell. > > The thing that *would* have got it is a "build all of CPAN", which we don't > have the resources to do for every change. So it gets down to - how do we > spot which changes need that sort of thing?
If it's not clear from context, I meant "smoke-me" as a substitute for 'Enhanced Smoking Techniques' we can apply to a branch. It's my fault for mis-using a term in an imprecise fashion. Show quoted text
>> Should then *all* changes go through a smoke-me change? I treat all of
> > I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't > have caught this one. > > (We'd need to improve the smoke-me reporting infrastructure to make this > useful though)
You yourself have pointed out in other threads that even *doc* changes can affect things like diagnostics.pm. Going down this road leads to a place where we'll get lost in the intractable problems which is why I wanted to cut it off early. I would love to have an infrastructure where we could smoke every commit against all of CPAN. The things we could do with such a tool would be amazing! Sadly we're not there yet. Show quoted text
> I think the key thing that was missing here was realising that this change > broke the CPAN smokers *reporting* setup. Which would have cut off reports, > and hence hidden the problems.
Having a failure mode that hides the complexity of the problem is a double whammy. Having a process to define where we need more canaries would be useful too. Show quoted text
> Regular automated smoke testing to be sure that the reporting setup isn't > broken seems like the first thing to fix. Unlike "all of CPAN", doing that > on a fast cycle seems tractable.
I'm certainly willing to help figure out how to make it happen. -Chris
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 11:27:46 +0000
To: Chris Prather <chris [...] prather.org>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 4.1k
On Wed, Feb 29, 2012 at 06:11:49AM -0500, Chris Prather wrote: Show quoted text
> On Wed, Feb 29, 2012 at 5:57 AM, Nicholas Clark <nick@ccl4.org> wrote:
> > [ignoring all other details, one point below]
> > [ditto] >
> > Putting it in a smoke-me branch would not have helped. That tests building > > the core with different configurations on different platforms. > > > > All tests passed for all core modules. That's all it can tell. > > > > The thing that *would* have got it is a "build all of CPAN", which we don't > > have the resources to do for every change. So it gets down to - how do we > > spot which changes need that sort of thing?
> > If it's not clear from context, I meant "smoke-me" as a substitute for > 'Enhanced Smoking Techniques' we can apply to a branch. It's my fault > for mis-using a term in an imprecise fashion.
It wasn't clear. I think that's obvious in hindsight :-) smoke-me specifically means platform testing from branches of git://perl5.git.perl.org/perl.git BBC specifically means "Bleadperl Breaks CPAN" - Andreas' testing setup for trying to build CPAN against a current(ish) build, and then (*very* usefully) trying to bisect down to the particular commit that broke things (which I think is only on x86_64 Linux, but I might be wrong) keep those terms for those things. everything else doesn't exist yet. Show quoted text
> >> Should then *all* changes go through a smoke-me change? I treat all of
> > > > I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't > > have caught this one. > > > > (We'd need to improve the smoke-me reporting infrastructure to make this > > useful though)
> > You yourself have pointed out in other threads that even *doc* changes > can affect things like diagnostics.pm. Going down this road leads to a
Sure, but they are not platform or configuration dependent. If people run the tests before they commit, such problems are spotted early. (Otherwise Jenkins will waggle a finger at them in public. The shame...) Show quoted text
> place where we'll get lost in the intractable problems which is why I > wanted to cut it off early. I would love to have an infrastructure > where we could smoke every commit against all of CPAN. The things we > could do with such a tool would be amazing! Sadly we're not there yet.
Which I think means that it's not as bad as that. Show quoted text
> > I think the key thing that was missing here was realising that this change > > broke the CPAN smokers *reporting* setup. Which would have cut off reports, > > and hence hidden the problems.
> > Having a failure mode that hides the complexity of the problem is a > double whammy. Having a process to define where we need more canaries > would be useful too. >
> > Regular automated smoke testing to be sure that the reporting setup isn't > > broken seems like the first thing to fix. Unlike "all of CPAN", doing that > > on a fast cycle seems tractable.
> > I'm certainly willing to help figure out how to make it happen.
That would be cool. I don't really think that I have the time to do more than this brain dump: It (first) struck me as something that could be automated with Jenkins. But I'm not *sure*. Does a) Jenkins maintain state? b) does it have a concept of a skip? In that, we need to avoid spamming with false positives. What *we* here are interested in is whether a change to blead broke the reporter modules. We don't want to confuse that with the modules themselves breaking. And it's not *that* easy to control the local CPAN mirror updates. So, probably one wants to do this: 0) snapshot CPAN. (eg, private local copy of CPAN, updated by this build script) 1) build blead with *parent of current commit* (5 minutes on fast hardware in parallel) 2) build reporter toolchain a) if it fails at this point, bail out as a "skip". (Warn about this?) b) otherwise continue 3) clean everything 4) build blead with current commit 5) build reporter toolchain (identical CPAN) and that's then "pass" or "fail", and conclusively did *this* blead commit break things (for the tested platform, which likely is the easy 90% to get right for starters) I also wonder whether anyone at the QA hackathon currently projectless would find this one interesting. Nicholas Clark
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 11:40:12 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.8k
Chris Prather wrote: Show quoted text
>You have suggested that any contentious change be put it into a >smoke-me branch. I agree. The problem was that this change wasn't seen >as being contentious.
Not quite the right criterion. We *did* know that this change would break some proportion of CPAN, and that a full-CPAN smoke test would be useful. This is not the case for most core changes, contentious or otherwise. We could (and I won't dispute that we should) have run the full-CPAN smoke test with the change parked on a branch, rather than putting it into blead first. I think I was emboldened to do that by the recent ", <$fh> line 123" addition in the same place, which raised exactly the same potential range of breakage (while actually hitting a considerably smaller proportion of CPAN). I was definitely made comfortable about applying straight to blead by the clear opportunity to revert it from blead before 5.15.8: I ensured we'd have time to make a decision on that. I didn't pay much attention to which modules turned out to be affected, just to how many (because that's how much effort it takes to fix), and ultimately I delegated the decision to our glorious pumpking. What would have made a difference here, and in similar situations, is an easy way to invoke the full-CPAN smoke test. We have smoke-me branches for testing a change across architectures and build options; I'd like to see a cpan-smoke-me mechanism for testing a change across CPAN distros. This would have given us the smoke results without so much (perceived) pressure for the change to go into a particular imminent release. It sounds like having some time to preemptively fix the affected modules would have resulted in fewer ruffled feathers. Overall, I don't think we totally bungled this, as Andreas surmised. We anticipated pain, and we took steps to measure and manage that pain, albeit imperfectly. It's a could-do-better. -zefram
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 09:26:37 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 6.8k
* "Andreas J. Koenig" [2012-02-29T02:18:50] Show quoted text
> >>>>> On Tue, 28 Feb 2012 20:19:57 -0500, Chris Prather <chris@prather.org> said:
>
> > [ ... ]
> Nope. I'd say we blew it major way. > > Changing such a heavily used module in a rush a few days before freeze > is not as excusable as you put it. Such a relatively irrelevant change > should have been postponed to the early phases of the next release > cycle. It was put into blead trunk. Instead of a smoke-me branch. And > Steffen's parallel smoke setup should have been involved *before* a > merge into blead trunk was even considered.
Steffen's smoke setup *was* involved, and the output was compared, and we found some 25-30 breakages. I said we should merge the change on the assumption that getting it into blead would be more likely to get more problems to the surface, and that should these problems seriously change the scope of the expected breakage, we could revert the change. There were some problems with this assumption, some of which have been pointed out, and some of which have not. * "Andreas J. Koenig" [2012-02-29T02:18:50] Show quoted text
> Sub::Uplevel was effected and reported. Since it is part of the > toolchain it broke the smoke process for *everything* for a few days.
For example, I didn't realize that the smoke reporting toolchain was affected like this. I'd seen Sub-Uplevel on the list, and considered the number of things hiding behind it, but not how they'd affect the reporters themselves. This was a tactical blunder. * "Andreas J. Koenig" [2012-02-29T02:18:50] Show quoted text
> A cheap excuse. We should stand to our mistakes. Development should slow > down in February and such changes should not be tried out in the trunk > ever. Let's put this into our book of mistakes that should not have > happened.
With hindsight, I would have done things differently. I don't agree that "changes should not be tried in the trunk, ever" though. As it stands now, smoke-me branches tend to get only smoking of the core tests. We don't have smoke-me CPAN smokers, other than Steffen, who must be asked to do it, and must set it up by hand. That means that getting an experimental change into blead, if the change doesn't break core, is a totally viable way to *then* get CPAN smoke reports. ...as long as it doesn't break smoke reports. As for it being February: yes, it was pretty late in the game. As Zefram suggested, I was emboldened by the *other* recent changes to Carp, which had already been release as stable to CPAN without causing massive chaos. What I overlooked as that they changed the error message in a *much* smaller set of cases. That is: I was thinking that the same set of people, give or take a small fraction, would be affected by this change. I think that's the most significant mistake I made. Had that been true, I think I'd still be pretty sanguine with how things went. * demerphq [2012-02-29T03:17:05] Show quoted text
> I think you have somewhat of a point, especially as regards timing. > However I think the counterpoint is that people should not be testing > raw output from core modules in the way that caused problems. We make > no commitments as to a particular output format in Carp, so hard > testing a snapshot of its output is unwise.
I'm not really happy with this counter-argument. The problem is that yes, people shouldn't be relying on the exact string output. They should be relying on an unchanging simple error identification API... which we don't provide. I thought about this, too, and hoped that by the next time we wanted to talk about changing this stuff, it would be to create the core exception types, and that we'd be doing the one last bodge-without-massive-improvement change now, preparing things for the future when these errors would be the same type of thing, and would necessarily stringify the same way. This was only a very minor consideration, though. * demerphq [2012-02-29T03:17:05] Show quoted text
> For instance, they could have checked to see if a fragment of the carp > output that was relevant to them.
In a nutshell: many did. For example, they only looked at the first line, which changed. If they tested for m{^You died at Foo.pm, line 2$} and we complain that this was too specific, what would we have them change? It's reasonable to check that it came from the same place. So they should've amended that to m{...line 2(?:[^0-9]|$)} or something? Bleh. I think that the affected test cases I saw were not unreasonable, in most cases. * Chris Prather [2012-02-29T05:32:57] Show quoted text
> Should then *all* changes go through a smoke-me change?
Certainly, many more of them should than now do. More of them should have a CPAN regression test. There are quite a few problems with making this a hard requirement, though, which boil down to shortages in resources, both human and computer. * Zefram [2012-02-29T06:40:12] Show quoted text
> Not quite the right criterion. We *did* know that this change would break > some proportion of CPAN, and that a full-CPAN smoke test would be useful. > This is not the case for most core changes, contentious or otherwise. > We could (and I won't dispute that we should) have run the full-CPAN > smoke test with the change parked on a branch, rather than putting it > into blead first.
Well, we *did* run it through a CPAN smoke. The problem was not looking at the list of affected dists, noting which were dependencies for other libraries (especially significant trees), fixing those, and then re-smoking. As I said much earlier, I thought we'd be able to revert the change if we determined it was a bigger problem than we'd expected. Now I'm concerned that this is not true, because somehow this got propagated as a way to fix the problem: $pattern .= $Carp::VERSION gt "1.24" ? "." :""; ...which means that a reversion in 1.30 would require all the libraries that were fixed in this way to be fixed *again*! * Zefram [2012-02-29T06:40:12] Show quoted text
> What would have made a difference here, and in similar situations, is an > easy way to invoke the full-CPAN smoke test. We have smoke-me branches > for testing a change across architectures and build options; I'd like to > see a cpan-smoke-me mechanism for testing a change across CPAN distros.
I agree wholeheartedly. It's a lot of work to make this happen, but it would be phenomenally useful, even if it was limited to one architecture and build. Especially if the mechanism was easy to re-use as more computing resources became available. * Zefram [2012-02-29T06:40:12] Show quoted text
> Overall, I don't think we totally bungled this, as Andreas surmised. > We anticipated pain, and we took steps to measure and manage that pain, > albeit imperfectly. It's a could-do-better.
This is my feeling, too. I made a judgment call, and in hindsight, I would have made it differently. Frustratingly, I believe I had all the information I needed to make the right one, and simply didn't put it all together at the time. But I don't plan to fall on my sword over this. I just plan to keep it in mind at similar junctures in the future. -- rjbs
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 15:52:01 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: demerphq <demerphq [...] gmail.com>
Download (untitled) / with headers
text/plain 3.6k
On 29 February 2012 15:26, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: Show quoted text
> * demerphq [2012-02-29T03:17:05]
>> I think you have somewhat of a point, especially as regards timing. >> However I think the counterpoint is that people should not be testing >> raw output from core modules in the way that caused problems. We make >> no commitments as to a particular output format in Carp, so hard >> testing a snapshot of its output is unwise.
> > I'm not really happy with this counter-argument.  The problem is that yes, > people shouldn't be relying on the exact string output.  They should be > relying on an unchanging simple error identification API... which we don't > provide.
That focuses too much on the details of the instant case. You need to zoom out and see how this is just an instance of a class of issues that we have in Perl dev, and that we simply cannot provide the kind of guarantee that people want for this kind of stuff. On the other hand, I agree with your point. When I dealt with the regex modifiers I actually created routines so people could access their patterns in such way that they could test that they had created the right ones without being sensitive to things like what modifiers we include in the pattern. So I am sympathetic with your proposed solution to the instant problem. But your reservations don't address the bigger issue. We simply cannot be hand-cuffed in what we change in Perl by people establishing hard dependencies on things we have not made promises about. If we do then we basically will never be able to release a change, fix bugs, correct typos, whatnot. Show quoted text
> I thought about this, too, and hoped that by the next time we wanted to talk > about changing this stuff, it would be to create the core exception types, > and that we'd be doing the one last bodge-without-massive-improvement change > now, preparing things for the future when these errors would be the same type > of thing, and would necessarily stringify the same way. > > This was only a very minor consideration, though.
I like the general idea. But again, it does not address my core point of commenting on this thread. Show quoted text
> > * demerphq [2012-02-29T03:17:05]
>> For instance, they could have checked to see if a fragment of the carp >> output that was relevant to them.
> > In a nutshell: many did.  For example, they only looked at the first line, > which changed.  If they tested for m{^You died at Foo.pm, line 2$} and we > complain that this was too specific, what would we have them change?  It's > reasonable to check that it came from the same place.  So they should've > amended that to m{...line 2(?:[^0-9]|$)} or something?  Bleh.  I think that > the affected test cases I saw were not unreasonable, in most cases.
How about ok($@=~/You died/ && $@=~/Foo\.pm/ && $@=~/line 2\b/); Anyway, the core point here is that if we have not made a promise about some feature then no-one can complain when change it. Its that simple. If a programmer decides to use unpublished API's in the Perl core and we remove them then its that programmers problem, not ours. I mean consider the massive list of things that we might have to worry about. Do we have to worry about backwards compatibility if we change the format of Devel::Peek output? What about the re=debug output? What about correcting typos in warning messages? The list is virtually endless. Anyway, all this aside, my view is that our default choice of action should always be to do things in such a way that it causes the least friction in the community but that we reserve the right to change things that we have not committed to keeping unchanged. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 10:20:30 -0500
To: perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 494b
* demerphq <demerphq@gmail.com> [2012-02-29T09:52:01] Show quoted text
> So I am sympathetic with your proposed solution to the instant problem. But > your reservations don't address the bigger issue. We simply cannot be > hand-cuffed in what we change in Perl by people establishing hard > dependencies on things we have not made promises about. If we do then we > basically will never be able to release a change, fix bugs, correct typos, > whatnot.
I totally agree with you on this general point. -- rjbs
Download signature.asc
application/pgp-signature 490b

Message body not shown because it is not plain text.

CC: Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 10:42:54 -0500 (EST)
To: Nicholas Clark <nick [...] ccl4.org>
From: George Greer <perl [...] greerga.m-l.org>
Download (untitled) / with headers
text/plain 1.5k
On Wed, 29 Feb 2012, Nicholas Clark wrote: Show quoted text
> In that, we need to avoid spamming with false positives. What *we* here are > interested in is whether a change to blead broke the reporter modules. > We don't want to confuse that with the modules themselves breaking. And it's > not *that* easy to control the local CPAN mirror updates. So, probably one > wants to do this: > > 0) snapshot CPAN. (eg, private local copy of CPAN, updated by this build > script) > 1) build blead with *parent of current commit* (5 minutes on fast hardware > in parallel) > 2) build reporter toolchain > a) if it fails at this point, bail out as a "skip". (Warn about this?) > b) otherwise continue > 3) clean everything > 4) build blead with current commit > 5) build reporter toolchain (identical CPAN) > > and that's then "pass" or "fail", > and conclusively did *this* blead commit break things
I had a script that did CPAN testers smoking against blead/maint-X that I stopped running a while ago because of the switch to metabase. Essentially it: 1) updated a minicpan 2) pulled and built blead or maint-X 3) did a CPAN testers module install from CPAN #1 with perl #2 4) ran CPAN testers against all the modules from #1 with perl from #2 5) go to #1 I had wanted to make it smarter so it kept state of the modules but dealing with all the modules that hung during tests was a pain and took up a lot of time, even with Andreas' blacklist. When I get home I'll see if I still have that around, at least. It might've been deleted during one of the Test::Smoke "delete everything" events. -- George Greer
CC: Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 10:46:43 -0500 (EST)
To: Nicholas Clark <nick [...] ccl4.org>
From: George Greer <perl [...] greerga.m-l.org>
Download (untitled) / with headers
text/plain 900b
On Wed, 29 Feb 2012, Nicholas Clark wrote: Show quoted text
> The thing that *would* have got it is a "build all of CPAN", which we don't > have the resources to do for every change. So it gets down to - how do we > spot which changes need that sort of thing?
If I can get a copy of the "build all of CPAN" script that the comparisons from a while ago were done with, I can try to set it up on a rolling basis. That is, it would compare blead from the last pass with whatever was blead at the start of the next pass. So it wouldn't be every change but it would at least be more than never. Show quoted text
>> Should then *all* changes go through a smoke-me change? I treat all of
> > I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't > have caught this one. > > (We'd need to improve the smoke-me reporting infrastructure to make this > useful though)
What's on your wishlist? -- George Greer
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 18:27:46 +0100
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: Alexander Hartmaier <alex.hartmaier [...] gmail.com>
Download (untitled) / with headers
text/plain 1.6k
Maybe I wasn't clear enough: if blead breaks some module on CPAN that's 'fine'.
But the problem wasn't blead but releasing a new version of Carp to CPAN which broke all stable Perl version installations.

I don't see how a blead smoke prevents that from happening for a dual-lifed module.
A warning in the Carp changelog would have helped (I read all changelogs before upgrading modules) if it was known at the time of release.
This kind of problem could only be solved by rerunning the tests of all downstream dependencies of a module after it has been updated which would require the test suites installed or redownloaded from CPAN.

-Alex (abraxxa)


On Wed, Feb 29, 2012 at 4:46 PM, George Greer <perl@greerga.m-l.org> wrote:
Show quoted text
On Wed, 29 Feb 2012, Nicholas Clark wrote:

The thing that *would* have got it is a "build all of CPAN", which we don't
have the resources to do for every change. So it gets down to - how do we
spot which changes need that sort of thing?

If I can get a copy of the "build all of CPAN" script that the comparisons from a while ago were done with, I can try to set it up on a rolling basis.  That is, it would compare blead from the last pass with whatever was blead at the start of the next pass.  So it wouldn't be every change but it would at least be more than never.


Should then *all* changes go through a smoke-me change? I treat all of

I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't
have caught this one.

(We'd need to improve the smoke-me reporting infrastructure to make this
useful though)

What's on your wishlist?

--
George Greer

Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 17:51:50 +0000
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 1.7k
Alexander Hartmaier wrote: Show quoted text
>But the problem wasn't blead but releasing a new version of Carp to CPAN >which broke all stable Perl version installations.
Interesting. It doesn't break *all* installations, but only those that upgrade Carp from CPAN. Since nothing at all declares a recent Carp as a versioned dependency (because Carp was only recently dual-lifed), you'll only get a Carp upgrade if you specifically choose to upgrade it or you blanket upgrade everything. Presumably that's what you're doing to have run into it. We have some blanket rebuilding of dependencies at my work, and ran into Carp breaking tests for an internal module (that I'd written). I wonder how common a practice it is to systematically upgrade everything. Some of the recent dual-life Carp versions have had more or less subtle portability problems for Perl 5.6. I didn't get any bug reports about this -- just ran into the problems myself in my routine CPAN testing -- so I presume that 5.6 users, at least, are not blanket upgrading. Show quoted text
>I don't see how a blead smoke prevents that from happening for a dual-lifed >module.
A smoke test of blead *against CPAN* (not just against the blead test suite) detects exactly this situation. Indeed, we did come up with a list of affected CPAN modules, before perl-5.15.8 and Carp-1.25 went out. If it had been a CPAN-only module then it could not have been tackled by any kind of blead smoke. Show quoted text
>A warning in the Carp changelog would have helped
The change was noted, but not explicitly marked as significant. Would a "significant change:" label on that entry have caught your attention sufficiently? I've used "incompatible change:" a couple of times, but that doesn't seem an appropriate categorisation for this change. -zefram
CC: Chris Prather <chris [...] prather.org>, "Andreas J. Koenig" <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>, Alexander Hartmaier <alex.hartmaier [...] gmail.com>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 21:34:49 +0100
To: Nicholas Clark <nick [...] ccl4.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 1.3k
On 02/29/2012 11:57 AM, Nicholas Clark wrote: Show quoted text
> The thing that *would* have got it is a "build all of CPAN", which we don't > have the resources to do for every change. So it gets down to - how do we > spot which changes need that sort of thing?
It's not just that. While I did expend the effort to write tools for CPAN smoking (hacky, yeah, I'll admit that) which have step-by-step instructions, and are all set up on a machine that all committers have access to, I'm still the only one who's ever volunteered to use it to do CPAN smokes. I suppose I could fill the gap between "run the following couple of commands, wait, look at HTML report" to get "click on the following button on a web page, wait, look at HTML report". But I doubt THAT level of automation is going to help very much. :( Show quoted text
> I think the key thing that was missing here was realising that this change > broke the CPAN smokers *reporting* setup. Which would have cut off reports, > and hence hidden the problems. > > Regular automated smoke testing to be sure that the reporting setup isn't > broken seems like the first thing to fix. Unlike "all of CPAN", doing that > on a fast cycle seems tractable.
Yes, but requires a fair amount of effort to set up and maintain. That's not free, particularly, since it'll be one of the people doing it that are otherwise spending their time on *different* useful stuff --Steffen
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 21:41:40 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 2.4k
On 02/29/2012 03:26 PM, Ricardo Signes wrote: Show quoted text
> * Zefram [2012-02-29T06:40:12]
>> Not quite the right criterion. We *did* know that this change would break >> some proportion of CPAN, and that a full-CPAN smoke test would be useful. >> This is not the case for most core changes, contentious or otherwise. >> We could (and I won't dispute that we should) have run the full-CPAN >> smoke test with the change parked on a branch, rather than putting it >> into blead first.
> > Well, we *did* run it through a CPAN smoke. The problem was not looking at > the list of affected dists, noting which were dependencies for other > libraries (especially significant trees), fixing those, and then re-smoking.
The CPAN smoke report has this data. In all fairness, it doesn't scream at you about it. :) Show quoted text
> * Zefram [2012-02-29T06:40:12]
>> What would have made a difference here, and in similar situations, is an >> easy way to invoke the full-CPAN smoke test. We have smoke-me branches >> for testing a change across architectures and build options; I'd like to >> see a cpan-smoke-me mechanism for testing a change across CPAN distros.
> > I agree wholeheartedly. It's a lot of work to make this happen, but it would > be phenomenally useful, even if it was limited to one architecture and build. > Especially if the mechanism was easy to re-use as more computing resources > became available.
I think I'd estimate this automation to be two full days of work to get something hecked up. AFTER understanding what's there. I'm not going to do it. And this all doesn't include the rabbit whole of understanding and working with the issues of properly cleaning up after the smokes, dealing with limited CPU time, dealing with limited scratch disk, etc. Doesn't take a rocket scientist, but a fair bit of toolchain clue, persistence and access to the system in question. Show quoted text
> * Zefram [2012-02-29T06:40:12]
>> Overall, I don't think we totally bungled this, as Andreas surmised. >> We anticipated pain, and we took steps to measure and manage that pain, >> albeit imperfectly. It's a could-do-better.
> > This is my feeling, too. I made a judgment call, and in hindsight, I would > have made it differently. Frustratingly, I believe I had all the information > I needed to make the right one, and simply didn't put it all together at the > time. > > But I don't plan to fall on my sword over this. I just plan to keep it in > mind at similar junctures in the future.
Agreed. --Steffen
CC: Nicholas Clark <nick [...] ccl4.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 21:44:14 +0100
To: Chris Prather <chris [...] prather.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 783b
On 02/29/2012 12:11 PM, Chris Prather wrote: Show quoted text
> You yourself have pointed out in other threads that even *doc* changes > can affect things like diagnostics.pm. Going down this road leads to a > place where we'll get lost in the intractable problems which is why I > wanted to cut it off early. I would love to have an infrastructure > where we could smoke every commit against all of CPAN. The things we > could do with such a tool would be amazing! Sadly we're not there yet.
It takes a Google-alike infrastructure to do that. Not just a couple of machines. So no, not going to get there. It'll need a bit of a judgement call. Also, we'd not only want to smoke each commit against its predecessor, but possibly also across wider ranges. Ouch. Combinatorial hell. :) --Steffen
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 14:44:39 -0600
To: Steffen Mueller <smueller [...] cpan.org>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 1.2k
On Wed, Feb 29, 2012 at 09:41:40PM +0100, Steffen Mueller wrote: Show quoted text
> On 02/29/2012 03:26 PM, Ricardo Signes wrote:
> >* Zefram [2012-02-29T06:40:12]
> >>What would have made a difference here, and in similar situations, is an > >>easy way to invoke the full-CPAN smoke test. We have smoke-me branches > >>for testing a change across architectures and build options; I'd like to > >>see a cpan-smoke-me mechanism for testing a change across CPAN distros.
> > > >I agree wholeheartedly. It's a lot of work to make this happen, but it would > >be phenomenally useful, even if it was limited to one architecture and build. > >Especially if the mechanism was easy to re-use as more computing resources > >became available.
> > I think I'd estimate this automation to be two full days of work to > get something hecked up. AFTER understanding what's there. I'm not > going to do it. And this all doesn't include the rabbit whole of > understanding and working with the issues of properly cleaning up > after the smokes, dealing with limited CPU time, dealing with > limited scratch disk, etc. > > Doesn't take a rocket scientist, but a fair bit of toolchain clue, > persistence and access to the system in question.
How much effort would it be to set this up on another machine? How much resources does it take? -doy
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 22:24:43 +0100
To: Jesse Luehrs <doy [...] tozt.net>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 2.8k
On 02/29/2012 09:44 PM, Jesse Luehrs wrote: Show quoted text
> On Wed, Feb 29, 2012 at 09:41:40PM +0100, Steffen Mueller wrote:
>> On 02/29/2012 03:26 PM, Ricardo Signes wrote:
>>> * Zefram [2012-02-29T06:40:12]
>>>> What would have made a difference here, and in similar situations, is an >>>> easy way to invoke the full-CPAN smoke test. We have smoke-me branches >>>> for testing a change across architectures and build options; I'd like to >>>> see a cpan-smoke-me mechanism for testing a change across CPAN distros.
>>> >>> I agree wholeheartedly. It's a lot of work to make this happen, but it would >>> be phenomenally useful, even if it was limited to one architecture and build. >>> Especially if the mechanism was easy to re-use as more computing resources >>> became available.
>> >> I think I'd estimate this automation to be two full days of work to >> get something hecked up. AFTER understanding what's there. I'm not >> going to do it. And this all doesn't include the rabbit whole of >> understanding and working with the issues of properly cleaning up >> after the smokes, dealing with limited CPU time, dealing with >> limited scratch disk, etc. >> >> Doesn't take a rocket scientist, but a fair bit of toolchain clue, >> persistence and access to the system in question.
> > How much effort would it be to set this up on another machine? How much > resources does it take?
Effort: It's a bit fiddly, but I'd say setting up another takes no more than a couple of hours once you got the idea. Making a single smoke span across multiple machines (if you don't want to smoke multiple commits separately)? Lots of effort in getting identical machines and quite some engineering effort to make the logic work. But at least the latter is fun. CPU? However much you can throw at it. Disk? Proportional to how much CPUs we have, since there's a fair bit of useless re-smoking that could be optimized in the underlying tools. I didn't have time and clue to do that, though. The current CPAN smoker runs for a couple of days (not quite a week, IIRC). It's running on a 100GB NFS share, taking a guesstimate of 2/3 of that for the active smoke. No, it's not disk-space efficient. The machine is a "Intel(R) Xeon(R) CPU E5420 @ 2.50GHz", which is a quad-core-eight-thread single-socket system. RAM is not an issue, but this one has 32GB. Disk cache probably helps a fair bit. So this isn't top of the line, but neither your mum's virtual server. This all being said, I'm perfectly willing to spend some time with you to get you started in improving my Jenga of hacks AS WELL AS giving hints about the practical setup. I believe you already have commit priviledges, so you can log in to "llama" from camel or dromedary. I think we (p5p) have more machines available for use by smokers. But for maximum benefit, that'll require some thought in scaling beyond the one. Cheers, Steffen
CC: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Wed, 29 Feb 2012 22:26:14 +0100
To: Jesse Luehrs <doy [...] tozt.net>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 730b
On 02/29/2012 09:44 PM, Jesse Luehrs wrote: Show quoted text
>> I think I'd estimate this automation to be two full days of work to >> get something hecked up. AFTER understanding what's there. I'm not >> going to do it. And this all doesn't include the rabbit whole of >> understanding and working with the issues of properly cleaning up >> after the smokes, dealing with limited CPU time, dealing with >> limited scratch disk, etc. >> >> Doesn't take a rocket scientist, but a fair bit of toolchain clue, >> persistence and access to the system in question.
> > How much effort would it be to set this up on another machine? How much > resources does it take?
Rats, forgot the link: https://github.com/tsee/cpan_perl_branch_smoke --Steffen
CC: Chris Prather <chris [...] prather.org>, perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Thu, 1 Mar 2012 11:37:50 +0100
To: Nicholas Clark <nick [...] ccl4.org>
From: Nick Perez <nick [...] nickandperla.net>
Download (untitled) / with headers
text/plain 4.6k
On Wed, 29 Feb 2012 11:27:46 +0000 Nicholas Clark <nick@ccl4.org> wrote: Show quoted text
> On Wed, Feb 29, 2012 at 06:11:49AM -0500, Chris Prather wrote:
> > On Wed, Feb 29, 2012 at 5:57 AM, Nicholas Clark <nick@ccl4.org> > > wrote:
> > > [ignoring all other details, one point below]
> > > > [ditto] > >
> > > Putting it in a smoke-me branch would not have helped. That tests > > > building the core with different configurations on different > > > platforms. > > > > > > All tests passed for all core modules. That's all it can tell. > > > > > > The thing that *would* have got it is a "build all of CPAN", > > > which we don't have the resources to do for every change. So it > > > gets down to - how do we spot which changes need that sort of > > > thing?
> > > > If it's not clear from context, I meant "smoke-me" as a substitute > > for 'Enhanced Smoking Techniques' we can apply to a branch. It's my > > fault for mis-using a term in an imprecise fashion.
> > It wasn't clear. I think that's obvious in hindsight :-) > > smoke-me specifically means platform testing from branches of > git://perl5.git.perl.org/perl.git > BBC specifically means "Bleadperl Breaks CPAN" - Andreas' testing > setup for trying to build CPAN against a current(ish) build, and then > (*very* usefully) trying to bisect down to the particular commit that > broke things (which I think is only on x86_64 Linux, but I might be > wrong) > > keep those terms for those things. > > everything else doesn't exist yet. >
> > >> Should then *all* changes go through a smoke-me change? I treat > > >> all of
> > > > > > I'd actually be happy if (nearly) all non-doc changes *did*. But > > > it wouldn't have caught this one. > > > > > > (We'd need to improve the smoke-me reporting infrastructure to > > > make this useful though)
> > > > You yourself have pointed out in other threads that even *doc* > > changes can affect things like diagnostics.pm. Going down this road > > leads to a
> > Sure, but they are not platform or configuration dependent. > If people run the tests before they commit, such problems are spotted > early. (Otherwise Jenkins will waggle a finger at them in public. The > shame...) >
> > place where we'll get lost in the intractable problems which is why > > I wanted to cut it off early. I would love to have an infrastructure > > where we could smoke every commit against all of CPAN. The things we > > could do with such a tool would be amazing! Sadly we're not there > > yet.
> > Which I think means that it's not as bad as that. >
> > > I think the key thing that was missing here was realising that > > > this change broke the CPAN smokers *reporting* setup. Which would > > > have cut off reports, and hence hidden the problems.
> > > > Having a failure mode that hides the complexity of the problem is a > > double whammy. Having a process to define where we need more > > canaries would be useful too. > >
> > > Regular automated smoke testing to be sure that the reporting > > > setup isn't broken seems like the first thing to fix. Unlike "all > > > of CPAN", doing that on a fast cycle seems tractable.
> > > > I'm certainly willing to help figure out how to make it happen.
> > That would be cool. I don't really think that I have the time to do > more than this brain dump: > > It (first) struck me as something that could be automated with > Jenkins. But I'm not *sure*. Does > > a) Jenkins maintain state? > b) does it have a concept of a skip? > > In that, we need to avoid spamming with false positives. What *we* > here are interested in is whether a change to blead broke the > reporter modules. We don't want to confuse that with the modules > themselves breaking. And it's not *that* easy to control the local > CPAN mirror updates. So, probably one wants to do this: > > 0) snapshot CPAN. (eg, private local copy of CPAN, updated by this > build script) > 1) build blead with *parent of current commit* (5 minutes on fast > hardware in parallel) > 2) build reporter toolchain > a) if it fails at this point, bail out as a "skip". (Warn about > this?) b) otherwise continue > 3) clean everything > 4) build blead with current commit > 5) build reporter toolchain (identical CPAN) > > and that's then "pass" or "fail", > and conclusively did *this* blead commit break things > > (for the tested platform, which likely is the easy 90% to get right > for starters) > > I also wonder whether anyone at the QA hackathon currently > projectless would find this one interesting.
Color me interest-piqued. I am not familiar enough with the entire toolchain but with a mentor, I could probably spend some time hacking on this. Show quoted text
> Nicholas Clark >
-- Nicholas Perez XMPP/Email: nick@nickandperla.net https://metacpan.org/author/NPEREZ http://github.com/nperez
CC: Perl 5 Porters <perl5-porters [...] perl.org>
Subject: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 17:12:55 +0100
To: George Greer <perl [...] greerga.m-l.org>, steffen [...] plum.flirble.org
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 2.9k
On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote: Show quoted text
> On Wed, 29 Feb 2012, Nicholas Clark wrote: >
> > The thing that *would* have got it is a "build all of CPAN", which we don't > > have the resources to do for every change. So it gets down to - how do we > > spot which changes need that sort of thing?
> > If I can get a copy of the "build all of CPAN" script that the comparisons > from a while ago were done with, I can try to set it up on a rolling > basis. That is, it would compare blead from the last pass with whatever > was blead at the start of the next pass. So it wouldn't be every change > but it would at least be more than never.
I think you'd need to ask Steffen where that is Show quoted text
> >> Should then *all* changes go through a smoke-me change? I treat all of
> > > > I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't > > have caught this one. > > > > (We'd need to improve the smoke-me reporting infrastructure to make this > > useful though)
> > What's on your wishlist?
I fear that this isn't complete, as I think I've forgotten something. It's partly that (as best I can tell) the code you're running locally has diverged from the "upstream" code, so it's unclear whether bugs fixes and other improvements are getting made in more than one place, which is a duplication of effort. In particular, I'd like everyone else to run your code, because of a couple of minor things: * the subject using the branch name is terser Smoke [blead] v5.15.9-20-g15d94df vs the tautological Smoke [5.15.9] v5.15.9-20-g15d94df Also those 1 or 2 characters can make a difference when the most important bit is actually the detail of PASS(...) or FAIL(...), which can fall off the right * the smoke-me code mails me directly if the branch fails * I can get the logs but also I'd like a couple of visibility bugs in your setup to be fixed: X X O X X X O X -Uusenm -Duseithreads -Dmad | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING | | | | +--- PERLIO = perlio -DDEBUGGING | | | +----- PERLIO = stdio -DDEBUGGING | | +------- LC_ALL = en_US.utf8 | +--------- PERLIO = perlio +----------- PERLIO = stdio 8 results vs 6 annotations, or 4 results vs 2 annotations: O F F F O F F F -Duseithreads | +--------- -DDEBUGGING +----------- no debugging after which I guess that there are more general skimming issues with the smoke output. I'm familiar with it, and I find it easy to read, but others are not paying attention to the smoke output because they perceive it as impenetrable noise. It would be useful force those people to explain what they find most obnoxious about it, fix that, iterate until they run out of complaints. First off, I'm not sure whether the line "Summary: PASS" (or FAIL...) should be the first line, with 2 (or 3) blank lines beneath it. But I'm not the target for such improvements - really the monthly release managers are the people whose input we should be getting. Nicholas Clark
CC: Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 17:15:20 +0100
To: George Greer <perl [...] greerga.m-l.org>, Steffen Mueller <smueller [...] cpan.org>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 976b
On Mon, Mar 26, 2012 at 05:12:55PM +0100, Nicholas Clark wrote: Show quoted text
> On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote:
> > On Wed, 29 Feb 2012, Nicholas Clark wrote: > >
> > > The thing that *would* have got it is a "build all of CPAN", which we don't > > > have the resources to do for every change. So it gets down to - how do we > > > spot which changes need that sort of thing?
> > > > If I can get a copy of the "build all of CPAN" script that the comparisons > > from a while ago were done with, I can try to set it up on a rolling > > basis. That is, it would compare blead from the last pass with whatever > > was blead at the start of the next pass. So it wouldn't be every change > > but it would at least be more than never.
> > I think you'd need to ask Steffen where that is
Oops, I don't have an alias for Steffen as "steffen". Correct cc now there. Clearly "spell checker" is not the only check I need before hitting "send" Nicholas Clark
CC: perl5-porters [...] perl.org
Subject: Re: [perl #106538] Carp is missing a dot
Date: Mon, 26 Mar 2012 17:26:44 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 1.6k
On Wed, Feb 29, 2012 at 09:26:37AM -0500, Ricardo Signes wrote: Show quoted text
> As I said much earlier, I thought we'd be able to revert the change if we > determined it was a bigger problem than we'd expected. Now I'm concerned > that this is not true, because somehow this got propagated as a way to fix > the problem: > > $pattern .= $Carp::VERSION gt "1.24" ? "." :""; > > ...which means that a reversion in 1.30 would require all the libraries that > were fixed in this way to be fixed *again*!
Sigh. Yes, encoding a new golden result is the short-term easiest fix. But it's not a *good* idea. Show quoted text
> * Zefram [2012-02-29T06:40:12]
> > Overall, I don't think we totally bungled this, as Andreas surmised. > > We anticipated pain, and we took steps to measure and manage that pain, > > albeit imperfectly. It's a could-do-better.
> > This is my feeling, too. I made a judgment call, and in hindsight, I would > have made it differently. Frustratingly, I believe I had all the information > I needed to make the right one, and simply didn't put it all together at the > time. > > But I don't plan to fall on my sword over this. I just plan to keep it in > mind at similar junctures in the future.
Including being in-your-face clear about what the right and wrong way to fix problems is, so that our path to reversing changes is clear and up front and if people are, um, *still* unwise enough to ignore it, "your problem"? It can be really quite frustrating how our maneuverability can be thwarted by poor decisions of CPAN code. I'm sticking to "poor" because it *should* be apparent to anyone with time to think, the implications of such a choice. Nicholas Clark
CC: George Greer <perl [...] greerga.m-l.org>, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 18:37:23 +0200
To: Nicholas Clark <nick [...] ccl4.org>
From: Steffen Mueller <smueller [...] cpan.org>
Download (untitled) / with headers
text/plain 1.5k
On 03/26/2012 06:15 PM, Nicholas Clark wrote: Show quoted text
> On Mon, Mar 26, 2012 at 05:12:55PM +0100, Nicholas Clark wrote:
>> On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote:
>>> On Wed, 29 Feb 2012, Nicholas Clark wrote: >>>
>>>> The thing that *would* have got it is a "build all of CPAN", which we don't >>>> have the resources to do for every change. So it gets down to - how do we >>>> spot which changes need that sort of thing?
>>> >>> If I can get a copy of the "build all of CPAN" script that the comparisons >>> from a while ago were done with, I can try to set it up on a rolling >>> basis. That is, it would compare blead from the last pass with whatever >>> was blead at the start of the next pass. So it wouldn't be every change >>> but it would at least be more than never.
>> >> I think you'd need to ask Steffen where that is
> > Oops, I don't have an alias for Steffen as "steffen". Correct cc now there. > > Clearly "spell checker" is not the only check I need before hitting "send"
It's here: https://github.com/tsee/cpan_perl_branch_smoke The README should mostly have step-by-step instructions. There's a whole bunch of gotchas such as requiring a fair amount of disk (in particular when running multiple processes for each commit). The other one is that the tempdir setting seems to be ignored by CPANPLUS. Whether that's due to CPANPLUS or the surrounding script I did not bother to find out. I just used TMPDIR=/foo/bar when kicking off the actual smokers. ... Let me know if you have questions. Best regards, Steffen
CC: George Greer <perl [...] greerga.m-l.org>, steffen [...] plum.flirble.org, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 11:39:52 -0500
To: Nicholas Clark <nick [...] ccl4.org>
From: Jesse Luehrs <doy [...] tozt.net>
Download (untitled) / with headers
text/plain 322b
On Mon, Mar 26, 2012 at 05:12:55PM +0100, Nicholas Clark wrote: Show quoted text
> Also those 1 or 2 characters can make a difference when the most important > bit is actually the detail of PASS(...) or FAIL(...), which can fall off the > right
Then wouldn't it be even more useful to have the PASS(...)/FAIL(...) bit first? -doy
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 18:52:12 +0200
To: perl5-porters [...] perl.org
From: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
Download (untitled) / with headers
text/plain 2.3k
On Mon, 26 Mar 2012 17:12:55 +0100, Nicholas Clark <nick@ccl4.org> wrote: Show quoted text
> On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote:
> > On Wed, 29 Feb 2012, Nicholas Clark wrote: > >
> > > The thing that *would* have got it is a "build all of CPAN", which we don't > > > have the resources to do for every change. So it gets down to - how do we > > > spot which changes need that sort of thing?
> > > > If I can get a copy of the "build all of CPAN" script that the comparisons > > from a while ago were done with, I can try to set it up on a rolling > > basis. That is, it would compare blead from the last pass with whatever > > was blead at the start of the next pass. So it wouldn't be every change > > but it would at least be more than never.
> > I think you'd need to ask Steffen where that is >
> > >> Should then *all* changes go through a smoke-me change? I treat all of
> > > > > > I'd actually be happy if (nearly) all non-doc changes *did*. But it wouldn't > > > have caught this one. > > > > > > (We'd need to improve the smoke-me reporting infrastructure to make this > > > useful though)
> > > > What's on your wishlist?
> > I fear that this isn't complete, as I think I've forgotten something. > > It's partly that (as best I can tell) the code you're running locally has > diverged from the "upstream" code, so it's unclear whether bugs fixes and > other improvements are getting made in more than one place, which is a > duplication of effort. > > In particular, I'd like everyone else to run your code, because of a couple of > minor things: > > * the subject using the branch name is terser > Smoke [blead] v5.15.9-20-g15d94df > vs the tautological > Smoke [5.15.9] v5.15.9-20-g15d94df > Also those 1 or 2 characters can make a difference when the most important > bit is actually the detail of PASS(...) or FAIL(...), which can fall off the > right
We can change that (too) Show quoted text
> * the smoke-me code mails me directly if the branch fails
That might be amongst several new options Show quoted text
> * I can get the logs
That will probably be possible too in the new setup. The QAH is just a few days away -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
CC: George Greer <perl [...] greerga.m-l.org>, Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 18:36:33 +0100
To: Jesse Luehrs <doy [...] tozt.net>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 659b
On Mon, Mar 26, 2012 at 11:39:52AM -0500, Jesse Luehrs wrote: Show quoted text
> On Mon, Mar 26, 2012 at 05:12:55PM +0100, Nicholas Clark wrote:
> > Also those 1 or 2 characters can make a difference when the most important > > bit is actually the detail of PASS(...) or FAIL(...), which can fall off the > > right
> > Then wouldn't it be even more useful to have the PASS(...)/FAIL(...) bit > first?
I thought about that, but forgot to say that that makes it hard to sort by subject in a mail client to get all results for the same platform together. Right now, sorting by subject is a fast way to determine when a platform started to fail (or pass) Nicholas Clark
CC: perl5-porters [...] perl.org
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Mon, 26 Mar 2012 18:37:56 +0100
To: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 920b
On Mon, Mar 26, 2012 at 06:52:12PM +0200, H.Merijn Brand wrote: Show quoted text
> On Mon, 26 Mar 2012 17:12:55 +0100, Nicholas Clark <nick@ccl4.org> > wrote:
Show quoted text
> > * the subject using the branch name is terser > > Smoke [blead] v5.15.9-20-g15d94df > > vs the tautological > > Smoke [5.15.9] v5.15.9-20-g15d94df > > Also those 1 or 2 characters can make a difference when the most important > > bit is actually the detail of PASS(...) or FAIL(...), which can fall off the > > right
> > We can change that (too) >
> > * the smoke-me code mails me directly if the branch fails
> > That might be amongst several new options >
> > * I can get the logs
> > That will probably be possible too in the new setup. The QAH is just a > few days away
This would all be cool. It's just is (probably) faster to integrate his code than re-implement it. Its your valuable Parisian drinking time I care for. Honest :-) Nicholas Clark
CC: Nicholas Clark <nick [...] ccl4.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Wed, 4 Apr 2012 21:02:07 -0400 (EDT)
To: Perl 5 Porters <perl5-porters [...] perl.org>
From: George Greer <perl [...] greerga.m-l.org>
Download (untitled) / with headers
text/plain 4.2k
(due to an ADSL outage this is copy/pasted from the web archives) Show quoted text
> On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote: >
> > What's on your wishlist?
> > I fear that this isn't complete, as I think I've forgotten something. > > It's partly that (as best I can tell) the code you're running locally > has diverged from the "upstream" code, so it's unclear whether bugs > fixes and other improvements are getting made in more than one place, > which is a duplication of effort.
My Test::Smoke customizations are: 1. Run 'make minitest' in addition to other tests. (Although I never did investigate how to get the report matrix to add that as a column...) 2. I moved the "user_note" to the very top of the reports instead of the bottom. (Currently used for URL to reports but also soon a disclaimer about my Win32 VM's propensity to have timing issues.) 3. Also allow ".config" suffix on configurations. (Previously "_config".) 4. Get version (what is between the brackets in smoke email subject line) from $ENV{TEST_SMOKE_BRANCH}, if present, instead of repeating Perl version. (This is what makes the "Smoke [blead]" in my reports.) Show quoted text
> In particular, I'd like everyone else to run your code, because of a > couple of minor things: > > * the subject using the branch name is terser > Smoke [blead] v5.15.9-20-g15d94df > vs the tautological > Smoke [5.15.9] v5.15.9-20-g15d94df > Also those 1 or 2 characters can make a difference when the most > important bit is actually the detail of PASS(...) or FAIL(...), > which can fall off the right
I thought that was rather silly too. I didn't add that to Test::Smoke in the best way though (via parsing ".patch") since my "smoke-me" script already adds the branch name as an environment variable and so that was fastest for tuit use. Show quoted text
> * the smoke-me code mails me directly if the branch fails
That's a function of the 'smoke-me' script, not Test::Smoke, although I agree it is a necessity for a 'smoke-me' service to do so. It's an unconditional email though, not just failures. My configuration for that is: driver/smoke-me_clang_quick.config.template: 'to' => 'smokers-reports@perl.org,%COMMITTER_EMAIL%', and the 'smoke-me' script does some variable replacements before making the .config file for Test::Smoke. (For those who may not know, the smoke-me script: https://github.com/greerga/smoke-me/ ) Show quoted text
> * I can get the logs
True, that's necessary for any 'smoke-me' service, Although the dashboard Tony Cook has is even better. (http://perl.develop-help.com/reports/) I wonder if he has that on github... Show quoted text
> but also I'd like a couple of visibility bugs in your setup to be fixed: > > X X O X X X O X -Uusenm -Duseithreads -Dmad > | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING > | | | | +--- PERLIO = perlio -DDEBUGGING > | | | +----- PERLIO = stdio -DDEBUGGING > | | +------- LC_ALL = en_US.utf8 > | +--------- PERLIO = perlio > +----------- PERLIO = stdio > > 8 results vs 6 annotations, or 4 results vs 2 annotations: > > O F F F > O F F F -Duseithreads > | +--------- -DDEBUGGING > +----------- no debugging
Yes, my adding 'minitest' to all runs did that. I do need to fix that. Show quoted text
> after which I guess that there are more general skimming issues with the > smoke output. I'm familiar with it, and I find it easy to read, but > others are not paying attention to the smoke output because they > perceive it as impenetrable noise. It would be useful force those people > to explain what they find most obnoxious about it, fix that, iterate > until they run out of complaints.
I agree. My biggest wishlist for Test::Smoke is (automatically) keeping track of when a test first started failing so it can differentiate between "failure" and "known failure", and while we're at it "sporadic failure" would be nice. I find the Test::Smoke code...dense...but then I've mostly only had time for drive-by changes to it and not been able to sit down and follow its flow. Show quoted text
> First off, I'm not sure whether the line "Summary: PASS" (or FAIL...) > should be the first line, with 2 (or 3) blank lines beneath it. But I'm > not the target for such improvements - really the monthly release > managers are the people whose input we should be getting.
There was a paucity of replies to this particular thread so we may never know. -- George Greer
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Thu, 5 Apr 2012 09:38:15 +0200
To: perl5-porters [...] perl.org, Abe Timmerman <abeltje [...] cpan.org>
From: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
Download (untitled) / with headers
text/plain 5.6k
On Wed, 4 Apr 2012 21:02:07 -0400 (EDT), George Greer <perl@greerga.m-l.org> wrote: Show quoted text
> (due to an ADSL outage this is copy/pasted from the web archives) >
> > On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote: > >
> > > What's on your wishlist?
> > > > I fear that this isn't complete, as I think I've forgotten something. > > > > It's partly that (as best I can tell) the code you're running locally > > has diverged from the "upstream" code, so it's unclear whether bugs > > fixes and other improvements are getting made in more than one place, > > which is a duplication of effort.
> > My Test::Smoke customizations are: > > 1. Run 'make minitest' in addition to other tests.
If others find that useful too, we should make that optional. Show quoted text
> (Although I never did investigate how to get the report matrix to add > that as a column...)
That should have been solved in the new setup Show quoted text
> 2. I moved the "user_note" to the very top of the reports instead of the > bottom. (Currently used for URL to reports but also soon a disclaimer > about my Win32 VM's propensity to have timing issues.)
That is in a template in the new version, moving it to other places is easy, but maybe not even necessary in the new database face. Our aim is to not send reports to a list at all (you can still send mail to yourself to get a copy). Show quoted text
> 3. Also allow ".config" suffix on configurations. (Previously "_config".)
Abe? Show quoted text
> 4. Get version (what is between the brackets in smoke email subject line) > from $ENV{TEST_SMOKE_BRANCH}, if present, instead of repeating Perl > version. (This is what makes the "Smoke [blead]" in my reports.)
As no mails will be send, this is moot Show quoted text
> > In particular, I'd like everyone else to run your code, because of a > > couple of minor things: > > > > * the subject using the branch name is terser > > Smoke [blead] v5.15.9-20-g15d94df > > vs the tautological > > Smoke [5.15.9] v5.15.9-20-g15d94df > > Also those 1 or 2 characters can make a difference when the most > > important bit is actually the detail of PASS(...) or FAIL(...), > > which can fall off the right
> > I thought that was rather silly too. I didn't add that to Test::Smoke > in the best way though (via parsing ".patch") since my "smoke-me" script > already adds the branch name as an environment variable and so that was > fastest for tuit use. >
> > * the smoke-me code mails me directly if the branch fails
> > That's a function of the 'smoke-me' script, not Test::Smoke, although I > agree it is a necessity for a 'smoke-me' service to do so. It's an > unconditional email though, not just failures. > > My configuration for that is: > > driver/smoke-me_clang_quick.config.template: > 'to' => 'smokers-reports@perl.org,%COMMITTER_EMAIL%', > > and the 'smoke-me' script does some variable replacements before making > the .config file for Test::Smoke. > > (For those who may not know, the smoke-me script: > https://github.com/greerga/smoke-me/ > ) >
> > * I can get the logs
In the new setup, logs are being sent to the database is the final status was not "PASS". This is configurable. Show quoted text
> True, that's necessary for any 'smoke-me' service, Although the dashboard > Tony Cook has is even better. (http://perl.develop-help.com/reports/) > > I wonder if he has that on github... >
> > but also I'd like a couple of visibility bugs in your setup to be fixed: > > > > X X O X X X O X -Uusenm -Duseithreads -Dmad > > | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING > > | | | | +--- PERLIO = perlio -DDEBUGGING > > | | | +----- PERLIO = stdio -DDEBUGGING > > | | +------- LC_ALL = en_US.utf8 > > | +--------- PERLIO = perlio > > +----------- PERLIO = stdio > > > > 8 results vs 6 annotations, or 4 results vs 2 annotations: > > > > O F F F > > O F F F -Duseithreads > > | +--------- -DDEBUGGING > > +----------- no debugging
> > Yes, my adding 'minitest' to all runs did that. I do need to fix that. >
> > after which I guess that there are more general skimming issues with the > > smoke output. I'm familiar with it, and I find it easy to read, but > > others are not paying attention to the smoke output because they > > perceive it as impenetrable noise. It would be useful force those people > > to explain what they find most obnoxious about it, fix that, iterate > > until they run out of complaints.
> > I agree. My biggest wishlist for Test::Smoke is (automatically) keeping > track of when a test first started failing so it can differentiate between
The new setup registers start time of every smoke-configuration subset and the duration thereof Show quoted text
> "failure" and "known failure", and while we're at it "sporadic failure" > would be nice. I find the Test::Smoke code...dense...but then I've mostly
Sporadic failures should now be detectable, as we store failures per test file, so you could make a trendline for e.g. op/read.t Show quoted text
> only had time for drive-by changes to it and not been able to sit down and > follow its flow. >
> > First off, I'm not sure whether the line "Summary: PASS" (or FAIL...) > > should be the first line, with 2 (or 3) blank lines beneath it. But I'm > > not the target for such improvements - really the monthly release > > managers are the people whose input we should be getting.
> > There was a paucity of replies to this particular thread so we may never > know.
We will be on #smoke in irc.perl.org to discuss wishes (when possible) -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
CC: perl5-porters [...] perl.org, Abe Timmerman <abeltje [...] cpan.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Thu, 5 Apr 2012 12:15:43 +0100
To: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
From: Nicholas Clark <nick [...] ccl4.org>
Download (untitled) / with headers
text/plain 4.8k
On Thu, Apr 05, 2012 at 09:38:15AM +0200, H.Merijn Brand wrote: Show quoted text
> On Wed, 4 Apr 2012 21:02:07 -0400 (EDT), George Greer > <perl@greerga.m-l.org> wrote: >
> > (due to an ADSL outage this is copy/pasted from the web archives) > >
> > > On Wed, Feb 29, 2012 at 10:46:43AM -0500, George Greer wrote: > > >
> > > > What's on your wishlist?
> > > > > > I fear that this isn't complete, as I think I've forgotten something. > > > > > > It's partly that (as best I can tell) the code you're running locally > > > has diverged from the "upstream" code, so it's unclear whether bugs > > > fixes and other improvements are getting made in more than one place, > > > which is a duplication of effort.
> > > > My Test::Smoke customizations are: > > > > 1. Run 'make minitest' in addition to other tests.
> > If others find that useful too, we should make that optional.
Well, I find it useful that at least one smoker is running it. I don't know what the right way to customise it is. Show quoted text
> > (Although I never did investigate how to get the report matrix to add > > that as a column...)
Show quoted text
> > 3. Also allow ".config" suffix on configurations. (Previously "_config".)
> > Abe? >
> > 4. Get version (what is between the brackets in smoke email subject line) > > from $ENV{TEST_SMOKE_BRANCH}, if present, instead of repeating Perl > > version. (This is what makes the "Smoke [blead]" in my reports.)
> > As no mails will be send, this is moot
Not totally. I'd still like to be getting mails for my failed smoke-me branches, and it's nicer with the branch name. Also, I'm not *sure* if I'd prefer to also opt-in to get e-mail for failures on blead (or any branch tested) if it was my fault - ie approximated by "the head commit was me", in which case it's also useful for it. But that's starting to sound more complex than just "convention is that smoke-me smokers notify on failure" with the opt-out being "well, don't create a smoke-me branch then" Show quoted text
> > > * I can get the logs
> > In the new setup, logs are being sent to the database is the final > status was not "PASS". This is configurable.
oooh. nice. Show quoted text
> > True, that's necessary for any 'smoke-me' service, Although the dashboard > > Tony Cook has is even better. (http://perl.develop-help.com/reports/) > > > > I wonder if he has that on github...
Good question. Show quoted text
> > > but also I'd like a couple of visibility bugs in your setup to be fixed: > > > > > > X X O X X X O X -Uusenm -Duseithreads -Dmad > > > | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING > > > | | | | +--- PERLIO = perlio -DDEBUGGING > > > | | | +----- PERLIO = stdio -DDEBUGGING > > > | | +------- LC_ALL = en_US.utf8 > > > | +--------- PERLIO = perlio > > > +----------- PERLIO = stdio > > > > > > 8 results vs 6 annotations, or 4 results vs 2 annotations: > > > > > > O F F F > > > O F F F -Duseithreads > > > | +--------- -DDEBUGGING > > > +----------- no debugging
> > > > Yes, my adding 'minitest' to all runs did that. I do need to fix that.
Yes, please magically find time to fix it :-) Although it might be better to spend that same time migrating to the new Test::Smoke code, if it makes it easier to add custom columns. Show quoted text
> > > after which I guess that there are more general skimming issues with the > > > smoke output. I'm familiar with it, and I find it easy to read, but > > > others are not paying attention to the smoke output because they > > > perceive it as impenetrable noise. It would be useful force those people > > > to explain what they find most obnoxious about it, fix that, iterate > > > until they run out of complaints.
> > > > I agree. My biggest wishlist for Test::Smoke is (automatically) keeping > > track of when a test first started failing so it can differentiate between
> > The new setup registers start time of every smoke-configuration subset > and the duration thereof >
> > "failure" and "known failure", and while we're at it "sporadic failure" > > would be nice. I find the Test::Smoke code...dense...but then I've mostly
> > Sporadic failures should now be detectable, as we store failures per > test file, so you could make a trendline for e.g. op/read.t
Nice Show quoted text
> > > First off, I'm not sure whether the line "Summary: PASS" (or FAIL...) > > > should be the first line, with 2 (or 3) blank lines beneath it. But I'm > > > not the target for such improvements - really the monthly release > > > managers are the people whose input we should be getting.
> > > > There was a paucity of replies to this particular thread so we may never > > know.
> > We will be on #smoke in irc.perl.org to discuss wishes (when possible)
I suspect we (also)(for some value of we) need to be more systematic in asking monthly release managers what confused them in the smoke reports. Easiest way to make that happen seems to be to make a question about smoke reports a regular fixture on the Onionsketch agenda. Nicholas Clark
CC: Perl 5 Porters <perl5-porters [...] perl.org>
Subject: Re: clearer smoke signals (was Re: [perl #106538] Carp is missing a dot)
Date: Thu, 12 Apr 2012 22:17:10 -0400 (EDT)
To: "H.Merijn Brand" <h.m.brand [...] xs4all.nl>
From: George Greer <perl [...] greerga.m-l.org>
On Thu, 5 Apr 2012, H.Merijn Brand wrote: Show quoted text
> On Wed, 4 Apr 2012 21:02:07 -0400 (EDT), George Greer >
>> 4. Get version (what is between the brackets in smoke email subject line) >> from $ENV{TEST_SMOKE_BRANCH}, if present, instead of repeating Perl >> version. (This is what makes the "Smoke [blead]" in my reports.)
> > As no mails will be send, this is moot
It does keep track of the git branch in the database though, correct? Show quoted text
>> "failure" and "known failure", and while we're at it "sporadic failure" >> would be nice. I find the Test::Smoke code...dense...but then I've mostly
> > Sporadic failures should now be detectable, as we store failures per > test file, so you could make a trendline for e.g. op/read.t
Is there functionality to ignore certain tests failing on particular servers? For example, my Win32 smoker fails various timing tests due to it being in a VM with a bouncy clock which aren't otherwise interesting. My Linux smoker though wouldn't have any clock problems (other than tests that make assumptions about load average). -- George Greer


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org