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. Second, I think emotions are the results of mammalian brains, perhaps bird and fish brains, and certainly not present in amoeba. > > 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 > >
