Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8

[Christoph Otto]

> -----Original Message-----
> From: parrot-dev-bounces at lists.parrot.org [mailto:parrot-dev-bounces at lists.parrot.org] On Behalf Of
> Andrew Whitworth
> Sent: Wednesday, December 01, 2010 11:51
> To: Patrick R. Michaud
> Cc: Andy Dougherty; parrot-dev at lists.parrot.org
> Subject: Re: Rakudo build broken as of parrot RELEASE_2_10_1-633-ga3ca6c8
> 
> 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.

I completely agree.  At Parrot's current stage of development we can't 
recommend that projects track master because of the energy that needs to 
be expended to keep up with what we break, but it's certainly helpful when 
they do.  Some of our misdeeds wouldn't have been caught without regular testing 
against an external project like Rakudo.

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

+1.  While we don't want to try to guarantee that Rakudo will always 
build against master, some kind of action is warranted to make breaks 
less common and minimally painful.  This process sounds like something 
worth considering.

> 
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev