On Thu, 6 Dec 2018 at 01:25, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote:
> 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. > An enlightening moment for me was reading an article about how PRs should not just be for the final product to integrate, but also be used heavily for discussion. Just put prepend something like "WIP" to the title. Then the PR is updated every time you commit to your source branch. There is even a github app to help manage that... https://github.com/wip/app#configuration https://github.com/wip/app/blob/master/pro-plan-for-free.js The "compare" tool is then available to draw attention to particular changes between particular commits... https://help.github.com/articles/comparing-commits-across-time/ cheers -ben 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" <esteba...@gmail.com> a écrit : > > > > 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> > wrote: > >> Hi Eliot, >> >> On 5 Dec 2018, at 14:46, Eliot Miranda <eliot.mira...@gmail.com> wrote: >> >> Hi Esteban, >> >> On Aug 7, 2018, at 4:36 AM, Esteban Lorenzano <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 > > 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 > > > >
