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>