[Pharo-dev] BlueInk removal

Torsten Bergmann astares at gmx.de
Thu Nov 28 04:03:56 EST 2019


To me it certainly looks like a <before we freeze Pharo 8 we have to speed up with features> to get things in
by all means. Have to admit I had this kind of "panic mode" myself several times in the past too ;)

Stef writes he now does not have the time nor energy - which I guess (including his reactions) is a tribute to his workload.
But then it would have been better to change to new Elumineire or getting rid of GTEventRecorder in Pharo 9 and now just marking
them for later exclusion. Because often we all underestimate the depencies, side effects, migration costs - even the reactions.

Meanwhile Pharo is not only the base image - it is the full ecosystem around it which is good and a positive sign and
something we IMHO need to respect more and more.

One has to understand that by just removing and not using deprecation the situation is getting worse and now pulling
more time and energy from other parts of the community too. Because broken stuff like Spotter, Settings, Roassal, Moose, ...
would need repair
 - either directly (to help contributors who use them in P8 alpha already to give quick feedback)
 - together with the Pharo 8 release so they can be used
 - after Pharo 8 is released (which would be very late and might include migration surprises)

Depreaction would help us better managing such transitions and is something that is standard in other languages too.

The alternative would be to say this is OPP (other peoples problem) and completely ignoring that projects are built on top
of Pharo base. We all know removing leads to being incompatible and is not helpful in offering a transition path - therefore not
a good option. Because then users would always need to start from scratch with each Pharo release and loose interest quickly.

Users want to do both: use Pharo and move their projects without having to focus on changed infrastructure
too often. Deprecation would give more room to fixing it- we have theses mechanisms like deprecations and we should really use them.

In the past we were able to move more freely - but now we should really accept that with more users we have to
follow certain backwards compatibility and more clear rules. This slows us down yes and requires more time
and energy. But it is still a good thing because Pharo is actually used and the community can grow.

We can not move Pharo into the "perfect" future with a crowbar as this would mean to loose users and especially
trust into the system. We might then still come up with an improved (but still imperfect) system in a few years -
but nobody would be interested anymore. If we fail to see things from the POV of the user then we will fail overall and loose them.

I agree with Benoit that especially business users first have to solve the customers problems before they
can juggle with migrations. So lets support the overall community and not being ignorant to it.
So far we all managed it quite good: moving from Pharo 6 to 7 and even Pharo 8 is working because things over the last
releases stabilized and also because we added more rules, depreactions, transformations and helping users.

I personally would prefer to see that "Pharo is not perfect but strong and widely used" than "look how cool it could have been",
so lets not get too impatient. Step by step - sometimes faster sometimes slower...

Thanks
T.



More information about the Pharo-dev mailing list