Deprecations and support

[Andrew Whitworth]

Thanks for the nice summary email, Coke.

I've said this a million times, but at the risk of sounding like an
extremely obnoxious broken record I'll say it again: I really wish
systems in Parrot which existed before the deprecation policy was
enacted were grandfathered in as "experimental" rather than as
"supported" by default. But, the damage is long-done at this point.

It's worth pointing out again that the threading system really is
broken. There are some tests, but even a cursory examination of them
will show that the tests themselves are broken too and are not really
testing for usable, or advertised, behavior. Saying that we're going
to remove something that we don't really have isn't really a situation
that I think is covered under the deprecation policy anyway.

If we ship a supported release with an obvious bug in a key system,
are we forced to support that bug for the next three months? By the
letter of the deprecation policy maybe we must, but I can't imagine
that strict adherence in this case is really helpful to anybody. If a
portion of our API is absolutely unusable, is it really part of our
API? Does it hurt anybody to remove such a feature with all possible
haste? Do we think that our end-users really want to be relying on
code that is known to be broken in our supported releases? That's what
our threading system is now, and has been through several releases:
known to be broken. The deprecation policy is a policy about
protecting users. That in mind, let me ask this: Who are we protecting
by keeping this code around?

If keeping our current broken threading implementation around
ultimately delays a proper usable implementation, our users will be
hurt, not protected. That's not good for anybody.

--Andrew Whitworth


On Wed, Jul 21, 2010 at 7:14 PM, Will Coleda <will at coleda.com> wrote:
> Regarding these specific deprecations, we have two PMCs, ParrotThread
> & Task, that I'm told are basically non-functional. (There are only
> the most trivial tests for these PMCs in their respective files, but
> there is a t/pmc/threads.t that seems to be /slightly/ more complete.)
>
> We need some kind of path for removal of this type of code - something
> that, based on conversations in IRC, should probably have been marked
> experimental before it was released.
>
> My first solution was going to be to rework the support policy a bit
> so that we could mark something that had already been released as
> "experimental", which I decided against given the impending release.
>
> My second solution is drawn from the desired path for replacing
> /working/ code - leave the old code in place, add the new
> functionality separately - in this case, since we're talking about
> replacing PMCs, you could - use different methods, leaving the old
> ones intact, or different PMCs altogether. (e.g. instead of Task, have
> Job or WorkUnit or...) There was resistance to this idea, especially
> because of the current state of the existing items.
>
> I think the least confusing option here is to extend the meaning of
> "experimental" and allow us to retroactively apply to those things
> that escaped our notice. (but this should be a last resort.) - We can
> put an entry in the Dep.pod, open a ticket (as per usual), mark it as
> experimental, and add a note that says "yes, this was shipped, nostra
> culpa."
>
> Even though the odds of someone using this are low, it is out there
> (and built and installed by default, and at least passing some
> tests.). - so if we're doing a drop in replacement (which I would
> argue we don't have to do if we just pick new names), we should have
> the new API spec'd ahead of time (which I now understand Chandon has
> already done as part of his GSOC project), and linked to from the
> ticket/wiki page for this change, so people can prepare.
>
> We're always going to be changing things, but we should make it as
> easy as possible on our users.
>
> Please note: we certainly have not been consistent in how we approach
> deprecations, or what falls under the the protection of the support
> policy. I'd just like to make sure we have a good process /going
> forward/.
>
> Thanks again to Chandon for all his work on the GSOC project - I'm
> sure it's going to end up in trunk sooner or later. =-)
>
> Regards.
>
> --
> Will "Coke" Coleda
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>