Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8

Andrew Whitworth wknight8111 at gmail.com
Wed Dec 1 19:50:49 UTC 2010


On Wed, Dec 1, 2010 at 2:23 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> 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.

I personally have never had anything nice to say about this particular
policy, but is it maybe time that we start considering some changes to
it? If our biggest user completely disregards it, that sounds to me
like a big problem with the policy.

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

I want to make this point very clearly: Parrot is *very* appreciative
of this aspect of Rakudo development. Rakudo devs routinely find bugs
that Parrot's test suite does not exercise, and this helps us in an
incalculable way. This feedback loop is a major reason why I want to
make absolutely certain that we are doing things in a way that Rakudo
wants us to do them in.

It is sounding to me like people want this kind of process:

1) Open a deprecation ticket on Trac
2) Update DEPRECATED.pod with eligibility date, link to trac ticket,
and (eventually) link to upgrade information.
3) Where possible (and I include the conditional because there are a
few very specific examples where this will not work) we put in an
alternative side-by-side with the existing feature for at least 1
[supported] release
4) Document the deprecation and the upgrade path clearly on Trac (this
is something we've talked about a while ago)
5) When the time comes, we make the final switch, preferably early in
the cycle so people have time to adjust before the next release

Is this sounding like a good process?

Deprecations used to be relatively straight-forward: Put in a notice,
wait time, change feature. We're obviously moving past that model to
something more robust but also more complex. I'm starting to think
that the DEPRECATED.pod document is simply not enough in terms of
record-keeping to manage what we are trying to do. I would be very
interested in suggestions for better ways to track these things.

--Andrew Whitworth


More information about the parrot-dev mailing list