Deprecation Policy and new GC

[Moritz Lenz]

Am 15.02.2011 03:54, schrieb Andrew Whitworth:
> It's not exactly a secret that I don't like our deprecation policy.
> Recently I think we've come to a point where it is far more
> detrimental to our status and progress than it is a benefit.

As a Rakudo developer, I have to agree.

We don't really use the deprecation announcements to migrate away from 
deprecated parrot features before the change is actually implemented.

There are a couple of reasons for that:
- some features don't have viable replacements at the time of the 
deprecation announcements
- it's not fun, and we are all volunteers
- it takes a lot of work/time
- some deprecations take quite long to carry out, so why bother with 
them now when we can hack on cool stuff instead?
- sometimes we simply forget

The deprecation policy does have some value, in that we can yell at the 
one who breaks stuff and don't get a bad conscience over the yelling. 
And also sometimes the deprecation notice tells us what to do to fix stuff.

But I think both benefits could be achieved with a less drastic 
deprecation policy too.

Sometimes we HLL developers are annoyed about how much parrot changes 
(though we do recognize the need for change). I just want to point that 
the deprecation policy doesn't itself reduce the amount of change we 
have to do, just the timing is different.

> So this brings us to the topic of the deprecation policy. The new GC
> creates an interface change by requiring the use of new write barriers
> on certain operations. According to the deprecation policy we would
> need to put in a notice now and wait 2 months until after the 3.3
> release before we could merge it. Then, since our users are supposed
> to be targetting our supported releases only, they wouldn't have a
> "supported" release with this new system in place until 3.6, 5 months
> from now.
>
> I find this unacceptable. Considering how important GC is, and how big
> a problem it is for us, I think it's unacceptable to simultaneously
> tell our users that we have a solution ready but they can't have it
> for almost half a year. And in that time we won't be getting valuable
> usage information, benchmarks, or feedback. We wont be able to
> effectively tune or optimize the system if people aren't regularly
> using it. If we don't have this in place by the 3.3 release at the
> latest, I think we are making a huge mistake.

Agreed. I want my 25%+ faster sooner than later.

> I find this situation to be extremely frustrating. I sincerely hope we
> can start a concerted discussion about this topic and find a
> resolution that is going to be acceptable to our developers and our
> users.

As a user, I quite like bacek's suggestion from IRC: instead of 
deprecating a feature, change it right away, but also provide patches 
for the users. (This can coexist with the current deprecation policy, ie 
a feature can either be slowly deprecated, or be changed fast with in 
conjunction with HLL patches).

I know that this scheme doesn't scale to too many users, and it doesn't 
work for closed source parrot-based projects, but I'm not aware that 
either of those should be a problem right now.

Of course this implies that we have some kind of submission process 
where a HLL developer can say "I have written language $x, and if you 
change parrot and bypass the deprecation policy, please conduct 
@these_steps to test my HLL", and then have access to a list of these 
submissions.


Just my 2 cents (and not speaking for all Rakudo developers),
Moritz