> On Jan 10, 2019, at 11:24 PM, ducasse <steph...@netcourrier.com> 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.
What do we understand by positive communication? Is it IS-style patting on the back for average performance some we don’t hurt people’s feelings or is it communication that advances a community’s work product? For me it is the latter. I would never dream of responding to technical criticism of the CM with a response that says “please refrain from criticizing us”. I try and respond honestly with an objective assessment of the technical, logistical and human issues. In fact I welcome criticism; how on earth will the VM improve in directions other than the narrow ones those working on it set without criticism from other stake holders? > > 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. > > 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 <b...@openinworld.com> wrote: >> >>> On Thu, 10 Jan 2019 at 23:51, ducasse via Pharo-dev >>> <pharo-dev@lists.pharo.org> 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 >> >
