Sven, > On Jan 11, 2019, at 11:40 AM, Sven Van Caekenberghe <[email protected]> wrote: > > > >> On 11 Jan 2019, at 19:32, Eliot Miranda <[email protected]> wrote: >> >> Sven, >> >>> On Jan 11, 2019, at 10:03 AM, Sven Van Caekenberghe <[email protected]> wrote: >>> >>> Eliot, >>> >>> I can assure you that multiple core Pharo people had the same reaction, >>> don't turn this (again) in a play on one person's emotions (apart from the >>> fact that those are present in all living creatures). >> >> First you assume a motive I don’t have. I am not trying to provoke anyone. > > Clearly you are, given the reactions. > > Like Doru said, you did not just answer the question, your last two > paragraphs contained lots of provocation.
You’re entitled to your opinion. But since the intent to provoke or not would be in my head you’re is a projection, not fact. > >> Second, I think emotions are the results of mammalian brains, perhaps bird >> and fish brains, and certainly not present in amoeba. > > First an IS reference, now this: yes, you are a man ratio and reason only, > devout of human emotions like the rest of us. Good for you. > > Hundreds of libraries and frameworks were moved between Pharo 6.x and 7, with > minimal changes. > > We are an active, living community where many, many people contribute, are > allowed to make mistakes, to question old code and old rules, to learn, to > make things better. > >>> Sven >>> >>>> On 11 Jan 2019, at 18:57, Eliot Miranda <[email protected]> wrote: >>>> >>>> Stef, >>>> >>>>> On Jan 10, 2019, at 11:24 PM, ducasse <[email protected]> wrote: >>>>> >>>>> Ben >>>>> >>>>> Since you asked I reply. >>>>> For calypso we try and sometimes fail and retry. But we do not rant. >>>>> >>>>> Now the solution is also to have tests and this is what we are doing. >>>>> We want more tests and we are working on having more tests. >>>>> >>>>> The solution is also to have ***********positive********* communication. >>>>> >>>>> There is no point to piss on our process because >>>>> - we were the first to push package usage back in squeal 3.9 >>>>> - increase enormously the number of tests >>>>> - have CI to run the tests and use PR. >>>>> and it is working! >>>>> >>>>> So before bashing us I would expect a bit of respect that it is due to >>>>> our track record. >>>> >>>> Again you fail to respond to an attempt to discuss real issues and instead >>>> take it as a personal map attack and respond emotionally. Ben is /not/ >>>> bashing your process in an attempt to damage Pharo. As an academic >>>> researcher you should be able to respond objectively to criticism. This >>>> frequent emotionality doesn’t help you or the community. >>>> >>>>> >>>>> Finally it takes 1 min to enter a bug entry and now you cannot even >>>>> complain that you have to log >>>>> because it is on github. (BTW nobdoy is asking the amount of time it >>>>> takes US to migrate and go over the bug entry - >>>>> again I ask for respect for the people doing this tedious, boring but >>>>> important job). >>>>> >>>>> When VMMaker will be available in Pharo we will be able to automate >>>>> things not before. >>>>> Please remember also that Igor paid by us spent a lot of time making sure >>>>> that >>>>> everybody and in particular our jenkins server could automatically build >>>>> vm. >>>>> >>>>> So we believe in agility, communication and automation. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>>> On 11 Jan 2019, at 05:54, Ben Coman <[email protected]> wrote: >>>>>> >>>>>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev >>>>>> <[email protected]> wrote: >>>>>> Thomas can you integrate such comments in the debugger class comment >>>>>> >>>>>> @Eliot thanks for the explanation. >>>>>> About the method removed, could you please react less negatively? It >>>>>> would be nice. >>>>>> I cannot believe that you the guy that know the VM would get stopped to >>>>>> open a bug entry telling us that isOptimizedBlock >>>>>> has been removed and it should not. How much time opening a bug entry >>>>>> can take? Under 1 min I guess. >>>>>> >>>>>> I'd guess it takes more than 1 minute overall - a few minutes to shift >>>>>> context to open an old Pharo image >>>>>> and a few more open the original method to copy it to Pharo and repeat >>>>>> that for the next ten missing methods, >>>>>> and then having fixed it for yourself, rather than just log a job for >>>>>> someone else, having fixed your own >>>>>> you now repair your pharo repo with Iceberg and submit a commit, and >>>>>> your now off-task by half an hour. >>>>>> Not a great deal of time if that was what you schedule to work on, you >>>>>> but frustrating when dragged off task. >>>>>> >>>>>> The thing is, when is someone is frustrated, without sharing there is no >>>>>> chance to resolve anything, >>>>>> so the frustration doubles and builds up, and unconsciously creeps in >>>>>> relationships and/or leads to a breakdown. >>>>>> Putting it out in the world relieves that pressure and provides the >>>>>> possibility that someone might >>>>>> find a middle path. As always, it is not what is said but how it is >>>>>> said, >>>>>> and personally that seemed okay to me. >>>>>> >>>>>>>> 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. >>>>>> >>>>>> On the flip side, if the rule was "don't touch unused methods", that >>>>>> would block a lot of action >>>>>> around cleaning, minimisation and modulation that are important. Even >>>>>> though those things >>>>>> aren't directly the shiney new tools that make Pharo great, its their >>>>>> philosophy that underpins >>>>>> a lot of the visible Pharo improvements which has facilitated Pharo's >>>>>> growth. >>>>>> That "vision" is why I'm here. >>>>>> >>>>>> The pivot point here the concept of "unused" and perhaps where we can do >>>>>> better. >>>>>> Currently developers have no information available to base their >>>>>> decision on. >>>>>> Requiring developers to query the mail list about every cleaning, >>>>>> minimisation and modulation action >>>>>> would have a freezing effect. >>>>>> >>>>>> For stuff that is image its much easier for developers since: >>>>>> * its "visible" right in front of them >>>>>> * they can make decisions and take action around it >>>>>> * tests can be run >>>>>> >>>>>> So the question is how we can get those things for important modules >>>>>> outside the image? >>>>>> For me, VM is not like any third party app but is very much a *part* of >>>>>> Pharo >>>>>> since its something which helps Pharo itself advance. So lets treat it >>>>>> as such, similar >>>>>> to how we treat other modules like Calypso or Iceberg which happen >>>>>> distributed in-Image. >>>>>> Can we consider the last step of the CI (after packing the CI product) >>>>>> could load a static version of VMMaker? Not that any issues would fail >>>>>> the commit, but just report >>>>>> to bring "visibility" to the table ? >>>>>> >>>>>> Or, once VMMaker is in git, perhaps a separate opensmalltalk-vm CI job >>>>>> could run against each latest Pharo image to report problems? >>>>>> >>>>>> Or to broaden the perspective of "unused" further, we could put broader >>>>>> #senders-info in front >>>>>> of developers so then can make informed decisions at design time rather >>>>>> cleaning up after-the-fact? >>>>>> Projects could register on a central site their list of #senders >>>>>> (generated from some tool) >>>>>> so the Pharo IDE could reference that when asked for #senders - so the >>>>>> information is available >>>>>> to make informed decisions. >>>>>> >>>>>> Clicking on an external#sender could pop up the actual code hosted on >>>>>> github, >>>>>> so developers have even better knowledge for decisions and >>>>>> communication. >>>>>> >>>>>> Of course, creating such a system requires effort in our world of >>>>>> limited resources. >>>>>> But the external#senders register could be a premium service available >>>>>> just >>>>>> to Pharo Association/Consortium members which sets up a bit of a win/win >>>>>> scenario. >>>>>> It helps developers and is an incentive to join up. This is not to >>>>>> guarantee changes won't >>>>>> affect your project's #senders, but just to improve communication around >>>>>> them. >>>>>> >>>>>> >>>>>> So why if marcus removed it inadvertently would you want to make him >>>>>> feel bad? I don’t want people to feel bad. >>>>>> >>>>>> We can do mistake. >>>>>> >>>>>> That is an important philosophy, but here is a key thing to be clear >>>>>> on... >>>>>> [ "If you are not open to hearing about mistakes, then you are not open >>>>>> to making mistakes." ] repeat. >>>>>> >>>>>> There is no reason for an individual to feel bad about removing an >>>>>> "unused" method if that is the process. >>>>>> But can the process be improved? >>>>>> >>>>>> cheers -ben >>> >>> > >
