Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8

[Patrick R. Michaud]

On Wed, Dec 01, 2010 at 10:45:11AM -0500, Andrew Whitworth wrote:
> On Wed, Dec 1, 2010 at 10:18 AM, Peter Lobsinger <plobsing at gmail.com> wrote:
> > I get the sense there's an expectation that rakudo should always build
> > and run cleanly against parrot head. I don't recall this ever being
> > explicitly supported, and I think that it is not feasible in the
> > general case (I do agree that in this specific case it would have been
> > a possibility).
> 
> What we really need to know are the exact parameters that Rakudo is
> willing to put up with during these kinds of disruptions, with the
> obvious tradeoff being that more tolerance towards disruptions brings
> more features and better performance, and brings all these things
> faster. 

First, let me add my strong +1 to the notion that a deprecated feature
should not be removed before its alternative has appeared in at least
one release (ideally at least one "supported" release).

As to what Rakudo is "willing to put up with"...  

IIUC, Parrot's official policy continues to be that HLL developers
should target "supported releases" only.  Rakudo explicitly and
knowingly ignores that policy, because advancing Rakudo at a reasonable
pace often means we need access to the new Parrot features long before
they'll be available in a supported release.  Indeed, we often need
them before they're available in a monthly release, which is why Rakudo
head often targets Parrot head and not simply monthly releases.

Because Rakudo doesn't follow Parrot's official policy, Rakudo is
willing to put up with a lot of disruption in Parrot head.  In other
words, Rakudo definitely requires "more features and better performance"
from Parrot over "stability", which is why our development targets
Parrot head and not Parrot releases, and we try to gracefully accept 
the inevitable disruptions that can come from that choice.

On the flip side, Rakudo often ends up serving as Parrot's canary in 
the coal mine, by exposing deprecation and other issues in Parrot head
before they get "solidified" into a Parrot release where they *would* 
impact users that are following the Parrot policy.  In other words,
if Rakudo developers weren't targeting Parrot head, would these sorts
of issues be detected before a Parrot release?  

So, Rakudo doesn't have an expectation that we can always build and
run cleanly against Parrot head; however, we'd like to have any
problems detected and resolved quickly, and definitely before the 
"non-building Parrot head" becomes "a non-building Parrot release".  
If a problem exists into a Parrot release, then Parrot and all of the HLL
users (not just Rakudo) have to scramble a bit to deal with the fallout.

That's the primary reason many of us test and build Rakudo against 
Parrot head, and why we report problems when they occur.  It's not 
that we expect Rakudo to always build and run cleanly against Parrot head --
it's that when Rakudo doesn't build and run cleanly against Parrot head, 
it likely points to a problem that could affect many Parrot users 
that ought to be fixed prior to the next Parrot release.

Pm