5.8.8-dor on cygwin status

2005-09-19 Thread H.Merijn Brand
Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
../lib/File/Temp/t/mktemp.t255 65280 98  88.89%  6-9
../lib/File/Temp/t/object.t255 6528026   42 161.54%  6-26
../lib/File/Temp/t/security.t   136  46.15%  3 5 7 11-13
../lib/File/Temp/t/tempfile.t  255 6528022   34 154.55%  6-22
io/tell.t   281   3.57%  28
op/filetest.t   101  10.00%  8
51 tests and 213 subtests skipped.
Failed 6/973 test scripts, 99.38% okay. 50/101291 subtests failed, 99.95% okay.

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.6, 5.8.7, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
  AIX 4.3, SuSE 9.2, SuSE 9.3, and cygwin.  http://www.cmve.net/~merijn
Smoking perl: smokers@perl.org, perl QA: http://qa.perl.org
  reports to: [EMAIL PROTECTED],perl-qa@perl.org



Re: 5.8.8

2005-09-13 Thread Nicholas Clark
On Mon, Sep 12, 2005 at 12:28:52PM -0500, Steve Peters wrote:
> The only other exception would be changes to re-entrant functions through
> reentr.pl, where the generated code is quite different than that in bleadperl.

Until and unless one of us figures out how to merge the code.

Nicholas Clark


Re: 5.8.8

2005-09-12 Thread Steve Peters
On Mon, Sep 12, 2005 at 05:29:39PM +0100, Nicholas Clark wrote:
> If there's a plan for 5.8.8, it goes roughly like this
> 
> 0: All changes that apply to maint are integrated from blead
> 
> 1: Changes should be in blead by midnight (GMT) on the 16th October 2005
> 
> 2: RC1 will probably appear within a week
> 
> 
> I'll be out of the country for the first week in October, and probably mostly
> incommunicado. I'll be in the country for the second week, but again mostly
> incommunicado. This definitely isn't a problem, as
> 
> a: how patches get into blead *isn't* my direct concern
> b: stable stuff isn't done as a last minute rush job
> 
> [You may read this as "if not being able to get patches into maint at the last
> minute worries you, then those patches will by definition worry me"]
> 
> Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then
> those patches have to go direct to maint. But I believe that little else
> does.
> 

The only other exception would be changes to re-entrant functions through
reentr.pl, where the generated code is quite different than that in bleadperl.

Steve Peters
[EMAIL PROTECTED] 



5.8.8

2005-09-12 Thread Nicholas Clark
If there's a plan for 5.8.8, it goes roughly like this

0: All changes that apply to maint are integrated from blead

1: Changes should be in blead by midnight (GMT) on the 16th October 2005

2: RC1 will probably appear within a week


I'll be out of the country for the first week in October, and probably mostly
incommunicado. I'll be in the country for the second week, but again mostly
incommunicado. This definitely isn't a problem, as

a: how patches get into blead *isn't* my direct concern
b: stable stuff isn't done as a last minute rush job

[You may read this as "if not being able to get patches into maint at the last
minute worries you, then those patches will by definition worry me"]

Clearly if anyone wants to fix bugs in pseudohashes or 5005 threads, then
those patches have to go direct to maint. But I believe that little else
does.

Nicholas Clark


Re: 5.8.8?

2005-08-09 Thread Nicholas Clark
On Tue, Aug 09, 2005 at 11:45:16PM +0200, Rafael Garcia-Suarez wrote:
> On 8/9/05, Alexey Tourbin <[EMAIL PROTECTED]> wrote:
> > Okay.  My concern is that bugfix changes are not tagged as "bufixes" (at
> > least as they come through perl5-changes), so there's a chance you can
> > miss the one when there's a lot of them.
> 
> I should get more verbose in my application logs...
> 
> > (Being more specific, I'm concerned about change #24367 (and also
> > changes #24703 and #24709) that fixes getppid() cache; the change was
> > made before 5.8.7 release and did not find its way into 5.8.7; there's
> > a chance it's not in again if you simply review the changes made after
> > 5.8.7 release.)

5.8.7 slipped quite a bit. I decided that it was better to get it out than
try to keep going through the backlog I had already. I will go through the
backlog, and it's actually easer to do so, because I don't have a direct
record of where 5.8.7's release came - the change messages all sit in a
mailbox and get deleted once I've concluded whether they are to be
integrated or aren't suitable.

> Yes, IMO this one should go in maint.

Yes, it looks like it should. (But there's looking quickly, and thinking
slowly and committing. And I don't think that 11pm is a good time to start
the latter)

Nicholas Clark


Re: 5.8.8?

2005-08-09 Thread Rafael Garcia-Suarez
On 8/9/05, Alexey Tourbin <[EMAIL PROTECTED]> wrote:
> Okay.  My concern is that bugfix changes are not tagged as "bufixes" (at
> least as they come through perl5-changes), so there's a chance you can
> miss the one when there's a lot of them.

I should get more verbose in my application logs...

> (Being more specific, I'm concerned about change #24367 (and also
> changes #24703 and #24709) that fixes getppid() cache; the change was
> made before 5.8.7 release and did not find its way into 5.8.7; there's
> a chance it's not in again if you simply review the changes made after
> 5.8.7 release.)

Yes, IMO this one should go in maint.


Re: 5.8.8?

2005-08-08 Thread Alexey Tourbin
On Mon, Aug 08, 2005 at 10:22:59PM +0100, Nicholas Clark wrote:
> > What if I'm interested in taking partial responsibility for this?
> 
> Whoever does maintenance tends to be drawn from someone who has already
> been committing to the development branch. I think that this would be more
> help would be useful. Actually merging across patches is relatively
> simple, once the decision is taken about what to merge.
> 
> I also think that there is considerable potential for confusion with more
> than one person doing it.

Okay.  My concern is that bugfix changes are not tagged as "bufixes" (at
least as they come through perl5-changes), so there's a chance you can
miss the one when there's a lot of them.

(Being more specific, I'm concerned about change #24367 (and also
changes #24703 and #24709) that fixes getppid() cache; the change was
made before 5.8.7 release and did not find its way into 5.8.7; there's
a chance it's not in again if you simply review the changes made after
5.8.7 release.)


pgpMZyQGUlS7W.pgp
Description: PGP signature


Re: 5.8.8?

2005-08-08 Thread Nicholas Clark
On Mon, Aug 08, 2005 at 02:38:38PM -0700, Yitzchak Scott-Thoennes wrote:
> On Mon, Aug 08, 2005 at 10:22:59PM +0100, Nicholas Clark wrote:
> > Whoever does maintenance tends to be drawn from someone who has already
> > been committing to the development branch. I think that this would be more
> > help would be useful. Actually merging across patches is relatively
> 
>   ^than ??

er, oops.

"I think that this would be *where* more help would be useful"

(ie the general development track stuff.
Particularly actually figuring out the causes of bugs and attempting fixes)

> > simple, once the decision is taken about what to merge.

and I notice that "about 1 month" is actually 2. So it seems that I can't
count either. Oops again.

Nicholas Clark


Re: 5.8.8?

2005-08-08 Thread Yitzchak Scott-Thoennes
On Mon, Aug 08, 2005 at 10:22:59PM +0100, Nicholas Clark wrote:
> Whoever does maintenance tends to be drawn from someone who has already
> been committing to the development branch. I think that this would be more
> help would be useful. Actually merging across patches is relatively

  ^than ??

> simple, once the decision is taken about what to merge.


Re: 5.8.8?

2005-08-08 Thread Nicholas Clark
On Tue, Aug 09, 2005 at 01:02:36AM +0400, Alexey Tourbin wrote:
> Hello,
> 
> Does someone integrate bugfixes into 5.8 branch?

Me.

(except that I've not done anything for about a month. I don't find this
worrying, as it's not time for a new maintenance release yet)

> What if I'm interested in taking partial responsibility for this?

Whoever does maintenance tends to be drawn from someone who has already
been committing to the development branch. I think that this would be more
help would be useful. Actually merging across patches is relatively
simple, once the decision is taken about what to merge.

I also think that there is considerable potential for confusion with more
than one person doing it.

Nicholas Clark