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).
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
