On Wed, 5 Dec 2018 at 23:29, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 5 Dec 2018, at 16:19, Ben Coman <btc@openinworld.com> wrote:
On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi Eliot,
On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Esteban,
On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Iâm slowly working on that VM because we want it to be the default for Pharo 8. In our vision, it should be a responsibility of the image to start or not a graphical UI, so we are preparing (we have been preparing to it for years, actually) to achieve this behaviour. To make this work, we need all platforms covered (and another huge quantity of changes here and there). Anyway, I didnât merge because I wanted to have win64 covered, not just what we have now, and since no-one was using that VM I didnât feel pression to do it :)
How does that answer Norbertâs question? By doing the work in your own fork you risk forking. Do you want to fork? If not, why not do the work in opensmalltalk-vm?
I guess you mean "why not do the work directly on the Cog branch of the OpenSmalltalk accountâ,
Thatâs not how you work on git/github and I prefer to keep it âas intendedâ.
because any other branch is no different to any other branch regardless of which account its stored in. The "opensmaltalk-vm repo" is a single big commit graph across all accounts, as you can see... https://github.com/OpenSmalltalk/opensmalltalk-vm/network
Whether any development-branch becomes a real-fork in the old vernacular is not how long it stays unmerged from the mainline-branch but how often the development-branch is updated to merge in the mainline-branch. The network graph is useful to understand the situation here.
This is old thing (there is a pull request now, since like 3 weeks).
I worked on my fork because thatâs how you do it with git: you fork, you work, and you do a Pull Request when ready. I was explaining why the PR was not still done: I wanted to have covered the three platforms before doing it.
On the flip side, release early release is a good policy.
Yeah, but for that you need to have something that you can release. minheadless was developed by Ronie (I just made the makefiles and adapted to build pharovms). And then it stalled around until I decided to took it and merge it⦠Iâm going to be susceptible and say that frankly I do not understand the tone of this mails.
It was your merge of minheadless into Cog that stimulated me to add my minor minheadless tweaks.
And Iâm grateful :)
I know I could have submitted a PR direct to your minheadless branch, but somehow it just felt more comfortable submitting it to the mainline Cog branch.
I guess the terminology is confusing you?
That doesn't help.
Why? Terminology *is* confusing, at least for me.
It came across sarcastic. My apologies. Email is a poor medium sometimes. cheers -ben