Proposal for using NQP-rx

Will Coleda will at coleda.com
Mon Nov 2 13:51:56 UTC 2009


This timing doesn't seem unreasonable to me. We have a similar,
de-facto  policy for branches, to give us time to settle down before
release. We won't necessarily be pulling this in every month, and the
week will give us time to test it before bundling it. If there are
issues, we can always back out the changes before the release; again,
just like we would for a branch.

On Mon, Nov 2, 2009 at 8:34 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> I think what I would really like to see is some sort of overview of
> what NQP-RX is, and what it does, that's different from our current
> NQP. I've heard that it improves regular expressions, but I don't know
> anything more specific than that. Assuming there are no regressions on
> functionality, and only a series of improvements, I'm generally in
> favor of this.
>
> The one thing I do worry about is the proposed timing. It seems like a
> week before the release isn't enough time if we have a major breakage
> somewhere and NQP needs to be updated again. What this would do,
> essentially, is enact a de facto feature freeze on changes that might
> affect NQP the week before every release. I'm not saying this is a bad
> thing, just pointing it out.
>
> --Andrew Whitworth
>
>
>
> On Sun, Nov 1, 2009 at 1:18 AM, Jonathan Leto <jaleto at gmail.com> wrote:
>> Howdy,
>>
>> I would like to propose that we upgrade NQP in Parrot core to NQP-rx
>> [0]. I have talked with pmichaud++ about this, and he is all for it.
>> Rakudo devs say that they would love to see NQP-rx in Parrot core as
>> soon as we are comfortable doing it. Of course, we need to consider
>> our deprecation policy. If there are no regressions, then the
>> deprecation policy does not come into effect, right? How does the
>> Parrot deprecation policy effect NQP? If we drop NQP-rx in as a
>> replacement, and "make fulltest" passes, as well as the entire Plumage
>> configure+build+test, I would call that "No detectable regressions."
>> We may want to test a few NQP-heavy HLL's, but I digress.
>>
>> Currently parrot installs plain old NQP as a parrot_nqp binary. The
>> new NQP-rx installs itself as an 'nqp' binary. All we need to do is
>> point our paths at the nqp binary and use that.
>>
>> Proposal: If the 'nqp' binary exists, prefer using that over
>> 'parrot_nqp' in all Parrot core that uses NQP. We obviously need
>> Configure-support for this.
>>
>> pmichaud++ prefers to keep NQP-rx as an external dependency, so
>> merging into Parrot core directly is not an option. He said that he is
>> fine with NQP-rx being used as an git submodule, for when we migrate
>> to git, or pulled into our current svn repo in some way. It uses the
>> Artistic License 2. He mentioned that he plans to release NQP-rx each
>> month the week before the Parrot monthly release.
>>
>> Duke
>>
>> [0] http://github.com/perl6/nqp-rx
>>
>> --
>>
>> Jonathan Leto
>> jonathan at leto.net
>> http://leto.net
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>



-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list