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" <[email protected]> a écrit : On 5 Dec 2018, at 16:19, Ben Coman <[email protected]> wrote: On Wed, 5 Dec 2018 at 21:53, Esteban Lorenzano <[email protected]> wrote: > Hi Eliot, > > On 5 Dec 2018, at 14:46, Eliot Miranda <[email protected]> wrote: > > Hi Esteban, > > On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <[email protected]> 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
