sound distribution practices

[Andrew Whitworth]

What if we did something like bundling? Practically speaking, for at
least the foreseeable future, Rakudo requires Parrot and the primary
user of Parrot is Rakudo. Offering two separate packages for such a
closely-knit pair almost seems like a waste (it won't always be, but
let's be honest about the current situation). As Jonathan and Patrick
mention, both projects are still in a "development" mode and not
really a "deploy" mode, in many ways, and changes in one are often
going to lead quickly to changes in the other.

I would love to see NQP and Rakudo snapshotted into Parrot
distributions or, as might be more favorable from a Rakudo
perspective, to have Parrot snapshotted into Rakudo release packages.
I obviously am not making the releases myself, so I don't know if this
is any easier for people in that role.

--Andrew Whitworth



On Sat, Apr 7, 2012 at 7:27 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Sat, Apr 07, 2012 at 03:24:37PM -0700, Allison Randal wrote:
>> These are things that Rakudo shouldn't care about. A bug-fix or
>> performance enhancement in Parrot is good, but doesn't actually affect
>> Rakudo's ability to build or run.
>
> Sometimes it does.  See the flurry of difficulties we had last April
> and May when Rakudo testing discovered that Parrot performance had
> declined by >100% over the previous several months (and Parrot
> developers were completely unaware of it).
>
>> Did the actual APIs change?  Different arguments required, or
>> substantially different behavior so that there was absolutely no way
>> Rakudo could run on both the old and new versions of Parrot?
>
> I can think of several instances where the APIs changed, such that
> Rakudo could no longer run on an older Parrot or would require
> substantial detection of which version of Parrot is being used
> and change code generation or behavior accordingly.
>
>> If so, then Parrot could be doing a better job of supporting
>> language development here, by preserving old APIs.
>
>> > One is due to getting a PAST improvement:
>> [...]
>> This is eager adoption of new features again. But, in this case I agree
>> the fix is that PAST should move to NQP and out of the Parrot packages
>> entirely. For one thing, having NQP depend on a library in Parrot that
>> depends on NQP is nightmarish for packaging.
>
> FWIW, I don't think this circular dependency exists (Jonathan doesn't
> think so either).  AFAIK, there's nothing in Parrot that has any sort
> of dependency on NQP.  (Note that there's a distinction between
> "nqp" and "nqp-rx"; Parrot includes some nqp-rx stuff, but doesn't
> make use of nqp.)
>
>> Indeed, not enough detail there for much analysis. But, in general there
>> is a difference between what you choose as your development process, and
>> what you choose as your release process. It is very sensible to always
>> test Rakudo against the latest versions of Parrot. But, that doesn't
>> mean you can stop testing against older version of Parrot. The most
>> important older versions to test against are the ones shipped in various
>> distributions.
>> [...]
>> It would also be helpful if Rakudo and NQP adopted more strategies to
>> keep the minimum required version as low as possible. Like "soft
>> launching" new features so they're simply not available when they depend
>> on a newer Parrot feature.
>
> I will go back and test, but I'm willing to hazard a guess that
> there are very few Rakudo releases that would be able to go very far back
> in Parrot's release history and still be functional, even with a sort of
> "soft launching" described here.
>
> For a recent and directly "on topic" example, take a look at
> https://github.com/perl6/nqp/commit/242f6e5997f6c454246fcf97b8a2a5d038d95931 ,
> provided to NQP by a Parrot developer on March 5.  This commit means
> that subsequent versions of NQP and Rakudo are absolutely unable to
> work with any version of Parrot prior to 4.2.0, because it's
> an API change.  I also don't see any "soft launch" for this commit
> that would make it easy for Rakudo/NQP to preserve access to
> older versions of Parrot.
>
> (Better would probably have been for Parrot to introduce a new opcode
> with the correct order of arguments rather than changing the API of
> an existing opcode, but that's not what happened here, and the API
> change was not introduced at the request of Rakudo/NQP.  As far as
> we can tell it came entirely from the Parrot development team.)
>
>> I guess that raises the question for me of whether Rakudo is ready to be
>> packaged. I don't have any trouble with Parrot packaging, but I do get a
>> regular series of unusual requests from the Rakudo packagers. If the
>> Rakudo project is totally focused on the use-case of downloading the
>> source code or checking out from git and compiling from source, maybe
>> it's just not ready for packaging.
>> [...]
>> I'm sure all the Rakudo packagers will agree with me that they'd really
>> hate to remove it from Debian. But, if packaging isn't something Rakudo
>> wants to support, then we shouldn't force the project into a different
>> mindset. To give you an idea of what Debian packaging is looking for,
>> take a skim through the upstream guide:
>
> I think this line of thinking reaches the wrong conclusions.
> What can be said with certainty is that for every Parrot release,
> there is at least one corresponding Rakudo release that can make
> use of that Parrot.  There's no reason to talk of "Rakudo isn't ready
> for packaging", because for any release of Parrot there is at least
> one contemporaneous release of Rakudo that can make use of it.
>
> What I suspect may be happening is that the Rakudo packagers
> are being a little over-eager about trying to provide the
> later versions of Rakudo, when there's not a packaged version
> of Parrot that can support them.  In this case, Rakudo's official
> suggestion would be for Rakudo packagers to stick to the most recent
> version of Rakudo that is compatible with whatever release of Parrot
> is available in that environment.  Since Parrot has a much slower
> release and packaging cycle, this does mean that Rakudo packaging
> will be limited by progress in Parrot packaging, but the Rakudo
> team is largely okay with that.
>
> I will do some work to find ways for Rakudo to maintain separate
> "desired" versus "minimum" versions of Parrot.  However, my
> past experience tells me that this won't really resolve the
> problem.  From Allison's original message:
>
>> Parrot isn't moving so fast that the APIs are all changing every month.
>
> Perhaps not every month, but our experience over the past year or so
> is that they do change every couple of months, in ways that directly
> affect Rakudo/NQP development (as illustrated by the 242f6e59 commit
> above).  Again, I'll do some investigation, but my suspicion is that
> over the past year, Rakudo and NQP would have been unable to hold
> the same "minimum Parrot revision" for more than two consecutive
> months.  Given the fact that both Parrot and Debian have "stable
> release cycles" longer than that, it's not clear that a minimum
> Parrot version would help much.
>
> Pm
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev