[Critisms] Parrot backward compatibility and docs

Andrew Whitworth wknight8111 at gmail.com
Fri Jun 18 11:34:46 UTC 2010


This seems to me like a perfect use for the parrot-users list, which
is under-used right now.

--Andrew Whitworth



On Thu, Jun 17, 2010 at 11:26 PM, Tyler Curtis <tyler.l.curtis at gmail.com> wrote:
> Something that could be helpful is a mailing list specifically for
> deprecations. Every modification to DEPRECATED.pod could either
> automatically or manually as a required part of the deprecation
> process be posted to the list, and when the deprecated feature was
> finally removed, a precise description of what has been removed, what
> the new way of doing it is, and how to migrate existing code to use
> the new way. So, someone developing on top of Parrot could subscribe
> to the list, and whenever a deprecated feature is removed, they could
> quickly use the included instructions in the message to the list to
> check whether they need to update their code and how to do so. Of
> course, the deprecation wiki page would also work, if it was kept
> updated. Really, the most important thing would be to have some
> handling of this aspect of the deprecation process, whatever that
> handling may be, specified and followed.
>
> On Thu, Jun 17, 2010 at 8:55 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
>> These are very good criticisms, and important for us to hear. By the
>> letter of the deprecation policy, a deprecation notice for the removed
>> ops was added in a supported release, but that notice was cryptic and
>> vague.
>>
>> To sort of enumerate some conflicting problems we have:
>>
>> 1) We need to be able to deprecate things. There are a lot of parts of
>> parrot (though the number is shrinking every month) that not good for
>> Parrot or it's users in general and need to be modified/removed. Out
>> with the old, in with the new, etc.
>> 2) Some issues aren't so pressing, but a few issues do need rapid
>> turnaround because people (especially Rakudo) end up waiting on
>> changes so they can make progress.
>> 3) Other people, such as yourself, like things to move a little bit
>> slower so you don't get the rug pulled out from under you.
>>
>> The current prevailing wisdom is that your project should not track
>> SVN HEAD. Instead, you should pick a stable release and track that
>> until you are ready to upgrade. So, my immediate suggestion is that
>> you pick a good stable supported release (2.3, and eventually 2.6) to
>> base your work against. Obviously, if you're following the
>> bleeding-edge development repository you're going to have to deal with
>> the hassles associated with that.
>>
>> The root issue is that we probably need to put more thought into our
>> deprecation notices. A good notice or linked ticket should, to my
>> mind, include:
>> 1) Detail about what exactly is changing or disappearing
>> 2) Detail about how to work around the changes, and where to go for
>> help if the given workarounds don't do it
>> 3) Information about the immediacy of the deprecation (important to do
>> quickly vs can take some time if necessary)
>>
>> We should probably also have a place where wayward developers can find
>>  a listing of all recent deprecation notices, so when something does
>> change people don't have to search too hard to find the information
>> they need.
>>
>> Thoughts?
>>
>> --Andrew Whitworth
>>
>>
>>
>> On Thu, Jun 17, 2010 at 9:22 PM, Kartik Thakore
>> <thakore.kartik at gmail.com> wrote:
>>> Hello folks,
>>>
>>> So after taking a bit of a break from hacking I was back to try the
>>> brand spanking new Parrot. Most of all I wanted to see how it worked
>>> with my naive attempt at parrotSDL
>>> (http://github.com/kthakore/parrotSDL). parrotSDL is an attempt to bind
>>> the SDL (http://libsdl.org) library to parrot using NCI. It would bring
>>> simple multimedia (think games) functionality to parrot.
>>>
>>> When I first started parrotSDL a few months ago I was excited with the
>>> promise of learning a really cool new language and platform. I had often
>>> wondered why no one else has done this yet; or for that matter any other
>>> bindings. Surely it couldn't have been that hard. For me the SDL pir sources
>>> was already in the parrot trunk, just not working.
>>>
>>> In hindsight that should have been my hint or rather a warning bell. Anyway,
>>> I quickly fixed a bunch of minor bugs and release them against the latest
>>> parrot trunk. The last commit was on February 25, 2010. A mere 5 months
>>> ago. And now parrotSDL is completely unusable now. The cause which seems
>>> completely ridiculous (printerr, cmod, .. etc now expects a ( ) around the
>>> string after it) to me as an end user.
>>>
>>> I have no doubt that there must be a good reason for this change in
>>> syntax. But I digress, as an end user this is very disappointing. If a
>>> library written in parrot is obsolete in 5 months ... what is the
>>> point?
>>>
>>> Moreover there is hardly a notice of what has been deprecated, so now I
>>> have to walk through svn logs, or hunt in varying places. And most
>>> annoying of all the docs provided by parrot are either obsolete or just
>>> too short.
>>>
>>> For me right now I really would like to push forward with parrotSDL, but
>>> I feel as if parrot was made by core developers for core developers.
>>> Which is fine, but I really hope that was not the only point of this.
>>>
>>> Regards,
>>> Kartik Thakore
>>> _______________________________________________
>>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>>
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
> --
> Tyler Curtis
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list