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