gistfile1.none

From: "Patrick R. Michaud" <pmichaud@pobox.com>
To: "Jonathan \"Duke\" Leto" <jonathan@leto.net>
Cc: Christoph Otto <christoph@mksig.org>,
	parrot-dev <parrot-dev@lists.parrot.org>
Bcc: 
Subject: Re: Parrot is a foundering project on top of a wonderful vision.
Reply-To: 
In-Reply-To: <CABQG1aQ39DYLGWmZ24jG-gSn_WH9VigDDngU4AFh7vgMV8uA+g@mail.gmail.com>

On Wed, Sep 07, 2011 at 12:46:37PM -0700, Jonathan "Duke" Leto wrote:
> As an aside, it would be awesome if somebody built Is Rakudo Fast Yet.

http://github.com/pmichaud/rpbench-results ,

> Parrot needs to distance itself from Perl 6 if we are ever going to interest
> the large majority of people that are interested in what Parrot has to offer.
> Most people in the sphere of VMs do not care about Perl 6.

This would seem to be very much at odds with what chromatic++ wrote in
http://www.modernperlbooks.com/mt/2011/08/no-policy-can-save-wrong-code.html:

   "The right solution is to invent a time machine and not kick Rakudo 
   out of the nest. (The rightest solution is to invent a time machine 
   and start implementing Perl 6 on Parrot from the first day as a 
   first-class citizen [...])."

I will willingly accept whatever focus Parrot chooses to have in this
regard.  However, if distancing Parrot from Perl 6 in 2009 was a mistake,
we might not want to repeat or reinforce it further in 2011.

> It also gives us a good reason to "push back" when
> Rakudo says "Don't Do That", even though we know we need to do something, for
> the good of Parrot. 

This phrase of "Rakudo telling Parrot 'Don't Do That'" keeps being repeated,
and I really want it to stop.  I've been unable to recall an actual instance
of me telling Parrot "don't make this change" for something that isn't
part of a published API.  (I'd be very happy to be proven wrong here, so
that I can admit the mistake and we can move on.  But I can't prove a 
negative.)  

If the complaints are coming from other Rakudo developers, they aren't 
"official Rakudo position" until you hear them from me or Moritz.
Also, remember that "Perl 6" != "Rakudo", and particularly #perl6 is not 
#rakudo.  Just because someone on #perl6 or using Perl 6 says something 
about Parrot doesn't make it Rakudo's position on the topic.  For an 
official statement of Rakudo policy, see either myself or Moritz.

For the complaints that _have_ been made, I believe I've tended to complain
not about the fact of the change itself, but rather about the lack of a
path to a viable alternative that we can use.  If the change to Rakudo is
simple to make, we make it and move on (and often don't say anything about
it).  If it's not, then we need Parrot's help to find a path, and sometimes
Parrot has not been helpful.

However, regardless of the past, let me try to make my (and Rakudo's)
official position abundantly clear now and for the future:

    1. Neither I nor Rakudo claim or desire veto power over any changes that 
    Parrot desires to make, for whatever reasons the Parrot developers may
    choose to make those changes.

    2. If some change does cause things in Rakudo to break, we'd like some
    help from Parrot developers in resolving the issue that goes beyond
    "your fault, deal with it."  The new relationship manager role should 
    help here but this has not been tested since the role was established.
    If the breakage is in a published API, we may complain, if the breakage
    is from Rakudo using unpublished internals, we will meekly accept
    responsibility for our transgression and not complain (but we may 
    still want help to find a resolution).

    3. When a change to Parrot is proposed (or made) that we feel is a 
    mistake, we feel some obligation as Parrot users to provide feedback 
    and say "that's the wrong path, please don't do it like that."  We 
    fully recognize and accept that Parrot has the right to choose whatever 
    path it wants, even over our objections.  Don't expect us to be
    completely happy with the result, though, and we may grumble about
    the choice from time to time afterwards if we feel it's a continuing
    mistake (as we have for the deprecation policy).

    4. If at any time or on any issue the Parrot leaders want us to stop 
    providing feedback or to treat some issues as being "decided and not 
    open for further debate", simply identify them and we will stop.

The above holds equally true for NQP as well as Rakudo.  If any of the above
seems ambiguous or unclear, let me know and I will try to clarify.

Pm