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