[Pharo-dev] Minheadless trial

Ben Coman btc at openinworld.com
Wed Dec 5 10:19:23 EST 2018


On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <estebanlm at gmail.com> wrote:

> Hi Eliot,
>
> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Esteban,
>
> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <estebanlm at 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",
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.
It was your merge of minheadless into Cog that stimulated me to add my
minor minheadless tweaks.
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.

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20181205/002b40b0/attachment.html>


More information about the Pharo-dev mailing list