Deprecations and support

[Will Coleda]

After parrotsketch yesterday, Chandon opened up two deprecation
tickets related to his GSOC project, which I ended up rejecting (and
removing the notices from the deprecated.pod).

Although I had even called for any last minute items in this vein,
Chandon and I both realized that, going forward, any deprecation
notices should probably go in at least a week ahead of a supported
release to allow sufficient time for discussion.

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