> On 5 Dec 2018, at 16:19, Ben Coman <b...@openinworld.com> wrote: > > > > On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@gmail.com>> wrote: > Hi Eliot, > >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.mira...@gmail.com >> <mailto:eliot.mira...@gmail.com>> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <esteba...@gmail.com >> <mailto:esteba...@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 > <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. Esteban > > cheers -ben
