3.8.0 Release Preparations

Kevin Polulak kpolulak at gmail.com
Sun Sep 18 23:33:14 UTC 2011


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 auto_release.pl <http://nopaste.snit.ch/81846> script
- a work in progress but still something I'll include in the release for
future managers).

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.

On Fri, Sep 16, 2011 at 7:23 AM, James E Keenan <jkeen at verizon.net> wrote:

> 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.
>
> 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.
>
> 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.
>
> 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.
>

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().

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.

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

--
- Kevin Polulak (soh_cah_toa)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20110918/562d0e04/attachment.html>


More information about the parrot-dev mailing list