[Pharo-dev] Minheadless trial

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Dec 5 12:24:27 EST 2018


Hi Esteban, Ronie,
Forking, branching and merging is certainly the clean way to do it!
The question is about the frequency of merges. Like Ben I prefer short
cycles, because otherwise we just can't review the code, it' too many diffs
at once. We can just trust, or not, take it or leave it...
So who is going to take the responsibility?

How i did it for win64 support? The canonicle way would have been to
develop a long branch with hundreds of changed files/lines, then merge when
ready. Instead of that, i integrated small batches of changes, none of
which were sufficient to have win64 working, but none of which completely
broke the trunk. Small steps... I know some purists that don't like my way
of doing because we obtain interleaved features in the history preventing
to easily bissect regressions, but i don't like puritanism either :).

In fact, i did experiment like Ronie in my own private fork, then when
ready, (not when perfect, but just when it reached a minimum of usability),
i redone everything in smaller steps (cherry pick, rebase, squash,
whatever...).

I did also commit some changes in trunk, or accepted my own merge, which is
questionable, but IMO more acceptable than rotting PR: that just means that
i have to assume the responsibility of changes, I break it, I repair it.
Ronie, you could adopt such strategy too, because in some aspects of the
VM, you are the expert :)!

It's certainly easier to concentrate on own changes and forget about the
drag of legacy, but it's only a short term view. The burden of integration
is differed, not eliminated, and the impact of changes not really mastered,
because at the end we say let's integrate now and see later what is
broken... We cannot always avoid such strategy when legacy code is too much
intricated... But in this case, my own view of refactoring is untwist
first, then replace.

I don't want to discourage good will, on the contrary, thanks a lot for
taking the burden of these essential changes!!! I rather want to encourage
more frequent refactorings. Don't hesitate to flood opensmalltalk with
small PR. They don't need to be perfect nor complete, as long as they go in
the right direction. Smaller changes means less burden and less
responsibility for the integrators, so more people can effectively
integrate, not just Eliot or Ben.

Cheers and thanks again!



Le 5 déc. 2018 16:29, "Esteban Lorenzano" <estebanlm at gmail.com> a écrit :



On 5 Dec 2018, at 16:19, Ben Coman <btc at openinworld.com> wrote:



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”,


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.

Esteban


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


More information about the Pharo-dev mailing list