Esteban,
On Jan 10, 2019, at 11:45 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 11 Jan 2019, at 08:24, ducasse <stepharo@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.
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 <btc@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 ?
You know? since we are sharing frustrations, I have to say: we already had that process (which was the old pharo-vm project). In that project, for each version of vmmaker we were loading it, generating a vm and running pharo tests there (since there are no vm-specific tests, this was working at least to test things were not broken). And⦠we were told this was not good and that we needed to submit to the canonical way of building the vm, which we did to not split more the community.
You were told nothing of the kind. You were told that the punch out the VM and build using CMake was technically an inferior solution and I stand by that; I have explained the technical resume many times before. I communicated that it was frustrating to get commits from you in which every version stamp changed (this was not your fault) because the Pharo Monticello/git integration was deficient and broke Monticelloâs merge logic; this remains a problem today.
In the process we lost all our validation process.
You could have made that validation process work in the current context. The current VM process includes validation for the Smalltalk dialects and Newspeak on Travis.
Now we are told that we remove things without caring.
As Craig pointed out I did not, and do not, say you donât care.
But we care, and we spent a lot of time and effort putting in place mechanisms to allow things to continue moving. And then we needed to throw it away.
Maybe now we have a new attempt and possibility of improving, but honestly I already spent one year of the work this community pays me to do to improve things and then it was wasted work. I do not thing I want to spend another âsabaticalâ year like that.
Esteban
Ps: Iâm sorry for the frustration rant, but when I see this things emerge I become very-very sad.
Yes, I understand your reaction; I have similar emotional reactions Iâm feeling my arm twisted to move to Pharo when my gut tells me it is too unstable and unfamiliar. But only by discussing and improving will either of us be able to work together in harmony. No ammount of meeting and reassuring each other as to our mutual respect and affection will help resolve conflicts which arise form technical realities that need to be addressed.
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