Now that it's Sunday. I would like the master branch to remain "mostly" 
frozen. "Mostly" meaning that if there's something trivial (e.g. a typo,
 a codingstd issue, additions to documentation, etc.), I won't mind if 
you commit those changes so long as you make me aware. Cleaning those 
little nooks and crannies at the last minute are fine by me. Only after 
Monday night though (all of Tuesday) do I want people leaving the master
 branch completely alone. That's when I'm going to be cutting the 
release (with the help of my new little <a href="http://nopaste.snit.ch/81846">auto_release.pl</a> script - 
a work in progress but still something I'll include in the release for future managers).<br>


<br>


So far, things appear to going well. The only failures on 'fulltest' are
 codingstd issues which I'm currently working on at the moment. The only
 other potential problem is that fact that my public SSH keys still do 
not work on our OSUOSL FTP server. I've opened a support ticket for this
 so hopefully it will be resolved before Tuesday night. Other than that,
 this shouldn't be a problematic release.<br>


<br>


On Fri, Sep 16, 2011 at 7:23 AM, James E Keenan <span dir="ltr"><<a href="mailto:jkeen@verizon.net">jkeen@verizon.net</a>></span> wrote:<br>



<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In
 late August a change was made that caused test #13 in t/dynpmc/select.t
 to begin failing on several OSes, Darwin among them. The test appears 
to have been TODOed on Win32 and Msys and not further addressed.  IIRC, 
benabik explained why this change would not work on Darwin (and, note, 
this means that the problem is not PPC vs Intel).  I believe others 
doubted the value of that particular test for any OS. But others said 
that the select dynpmc needed to be maintained, if only on 
'experimental' status, because of Rakudo's needs.<br>
<br>
Whichever is the case, this problem needs to be addressed before the 
release.  Personally, I think if we acknowledge that a feature is 
experimental, it ought to be retained in master *only* if its tests pass
 on all of our supported platforms.  The change made in late August 
appears to pass only on Linux and possibly the BSDs.<br>
<br>
The reason I recommend this is that too often, TODOing failing tests for
 particular OSes is tantamount to sending the underlying problem to 
/dev/null.  This is particularly so when, as the case is here, the 
particular test had been PASSing for years on all our supported 
platforms and started to FAIL at a clear point in time.<br>
<br>
My feeling is that the changes in the select dympmc should never have 
been merged into master at all and should be reverted.  Those of us who 
think it should stay in master now ought to address its continuing 
problems.<br>
</blockquote></div>


<br>

Actually, I ran into other problems yesterday with t/dynpmc/select.t 
too. Apparently, it was leaving behind a README2 file. I was able to fix
 it with a simple call to unlink() but it also forced me to look into 
the experimental nature of select().<br>


<br clear="all">


It obviously needs to be tested but if the behavior is not defined on 
MSWin32-related systems, I'm not sure that we really have any other 
options other than simply skipping them. I do think we need to add 
socket-based tests though (not just for MSWin32 but all OSes). I'll do 
some research and look at how the IO::Select handles its tests but even 
so, I'm not sure we have enough time to 1) add those tests and 2) have 
them thoroughly tested and passing on several platforms before Tuesday 
night.<br>

<br>
This has been a long-standing issue and so I agree with you in that it definitely needs to be addressed now.<br>
<br>


--<br>


- Kevin Polulak (soh_cah_toa)<br>