On 11 Jan 2019, at 09:58, Craig Latta <craig@blackpagedigital.com> wrote:

Hi all--

    Eliot writes:

Do you want to remove the method simply because there are no senders
in the image?

If so, this is indicative of a serious problem with the Pharo
development process.  In the summer I ported VMMaker.oscog to Pharo 6.
Now as feenk try and build a VMMaker.oscog image on Pharo 7, the
system is broken, in part because of depreciations and in part because
useful methods (isOptimisedBlock (isOptimizedBlock?) in the Opal
compiler) have been removed.

Just because a method is not in the image does not imply it is not in
use.  It simply means that it is not in use in the base image.  As the
system gets modularised this issue will only increase.  There are lots
of collection methods that exist as a library that are not used in the
base image and removing them would clearly damage the library for
users.  This is the case for lots of so-called system code.  There are
users out there, like those of us in the vm team, who rely on such
system code, and it is extremely unsettling and frustrating to have
that system code change all the time.  If Pharo is to be a useful
platform to the vm team it has to be more stable.

    Esteban responds:

...we are told that we remove things without caring.

    I don't see where Eliot said anyone didn't care.

    Stef responds:

About the method removed, could you please react less negatively? It
would be nice.

...

How much time opening a bug entry can take? Under 1 min I guess. So
why if marcus removed it inadvertly would you want to make him feel
bad?

    Eliot said the system has to be more stable. It doesn't seem like a
negative reaction, or an attempt to make anyone feel bad. As Ben pointed
out, the major cost of reporting regressions isn't the time spent
interacting with the bug-tracking system, it's being switched away from
what you were doing. Using the automated regression-testing system seems
like a good way of catching this particular issue (even though it's a
step away from having full live traceability all the time, before
committing changes).

For calypso we try and sometimes fail and retry. But we do not rant...
The solution is also to have ***********positive*********
communication... There is no point to piss on our process... So before
bashing us I would expect a bit of respect that it is due to our track
record... it would be nice if you could refrain to be systematically
negative about what we are doing.

    I don't think Eliot is being systematically negative, or that he
was ranting, pissing, or bashing. I think introducing those accusatory
words into the conversation detracts from positive communication.

I think that we are doing a great job make Smalltalk cool.

    I do, too! (And thanks for using that word. ;)


    thanks,

-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
craig@blackpagedigital.com
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)