2018-03-31 15:03 GMT+02:00 Esteban Lorenzano
<estebanlm@gmail.com>:
you are right in all points, but for me this is a problem of process.
- we have no defined milestones so nobody knows if they can jump to help.
- plugin development happens “by his own” and nobody knows what happens, why happens and how it happens.
- infrastructure is not bad and a lot of efforts has been made to make it work. But code sources are scattered around the world and the only thing that reunites them is the hand of the one who generates the C sources.
IMHO, is this “disconnection” what causes most of the problems.
cheers,
Esteban
Hi Esteban,
Maybe the Pharo team is willing to collaborate and take active parts in definition of milestones?
If we want to make progress, we should ask why it is so.
We could analyze the regressions, and decide if the complexity is sustainable, or eventually drop some drag.
We are chasing many hares by building the VM for Newspeak/Pharo/Squeak i386/x86_64/ARM Spur/Stack/V3 Sista/lowcode linux/Macosx/Windows ...
If it happens that a fix vital for Pharo/Squeak does break Newspeak tests, then it slows down the progress...
Maybe we would want to decouple a bit more the problems there too (they may come from some image side weakness).
This happened just once or twice. And it was because people were ignorant of “joint" so they continued contributing as before (and people were pointed to right place when we had the opportunity).
And I disagree this was counterproductive because I took the effort to merge the changes into osvm. This worked fine until I stopped to do that job, but well… just one PR got stalled there for months and Alistair integrated it recently.
What *did happen* and I’m still not ready to let it go is a lot of the small changes that we presented to be rejected (or ignored) without further consideration. But well, let’s keep it positive and not enter to sterile discussions, I just think you are wrong with this argument.
No, it's important, we (opensmalltalk-vm team) can't let such bad feeling and frustration creep in.
Every contribution counts, that does not mean that every PR will be accepted, but we owe an explanation if not.
Some are accepted instantly, some are accepted after modification requests, some are rejected (I hope with some rationalization).
What is problematic is that some were ignored for too long time, I regret the situation, but there is no deliberate intention to ignore them, just lack of manpower IMO.
For example, the recent work of Alistair shows that there is no fatality here, it's just that someone has to do the hard work (kudos!).
I’m sorry for have a bitter feeling, but I’m going to give you an example so you understand why I’m saying this: I proposed the refactor of Alien package (which is obviously right and simple) at least three times in last three years (by different means). First time I’ve been told “no, we prefer it like that”. Second time I’ve been told “we need to think about that” (and no answer later). Last time I even didn’t receive a response. So well, when Torsten proposed it he first came to me. I told him “talk in vm-dev and good luck”. His proposal was accepted (thanks god).
Several situations like this one made me think that I’m a second class citizen in this community. And you know what? I’m 46 years and I do not want to be treated as is I’m a child that can play with the toys someone let me or not. So yes, I’m sad and not very “into” this this days. I made a lot of efforts to came back for the de facto fork we had because I always pushed to work together. But I do not see the spirit of collaboration I hoped.
Also, the question is coupled with stability: having a red status does not help, for almost every PR that I accepted, I had to dig into travis console reports and compare to status of previous build in order to know if it was a regression, or just a long time failing case... This does not scale!
is worst that "does not scale".
again, let me put you an example: Imagine I want to work on FFI and I need to touch both an external file and VMMaker: I cannot do a PR because VMMaker is not there and VM building will be broken and I cannot push VMMaker because platform sources are not there and VM building will be broken too.
So, the only solution is what happens today: I need to push VMMaker and changes at the same time. So I’m forced to work on the development branch (we are all forced to work there), instead how I think it should be: each one should be able to work on their branch and contribute changes through PRs (PRs that can be validated with a good CI process).
As a consequence, since all contributions go to the development branch… we have no stability and we need to wait of the blessing of a VM. That may or may not happen.
Meh, whatever… is obvious that my way of work is different to most of the people of this community so I will go back to what I do now: just the absolutely necessary.
cheers,
Esteban
ps: I will not continue discussing this… I know how things are and I’m sorry to put such a negative perspective in this list, but I needed to say it.
I'm all for more distributed power, and that should come with responsibilities, first a cooperative "you break it, you fix it" attitude.
Or maybe do you want clarified decision process?
For now, people that feel interested by a PR raise their voice.
I don't know if we need something more formal
For important design decisions there is vm-dev mailing list to discuss about that.
cheers
Nicolas