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