<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Yes, Keith, that's too difficult, because you have to know that patchA<br>works in Pharo 11231, Pharo 11232 etc...<br>Then you also have to know if patchB works in Pharo 11231+patchA,<br>Pharo 11232+patchB etc...<br>Try the combinations of trunk patches and come back with real facts.<br></div></blockquote><div><br></div>Hi Nicolas, </div><div><br></div><div>Why are you trying to patch a moving target, with fixed patches. Of course if the target moves the patches have to move with the target, in the lower layers. Higher architectural levels should be isolated from such changes. </div><div><br></div><div>I am saying that you need to patch a fixed target with fixed patches in a prescribed order if an order is needed, spend time getting it working, and release a new fixed target. The result will be release of images at fixed points A and B, with a prescribed detailed process of exactly how you got from release A to release B. That is a useful and desirable result because it captures the knowledge as well as producing a new image. Capturing the knowledge is the important enabler for cross fork working, and for maintaining the map of load-able packages across forks.</div><div><br></div><div>Secondly you divide the target vertically into modules and subsystems, so that the problem is split up among different teams/individual experts.</div><div><br></div><div>Thirdly you divide the target horizontally into architectural layers, and within each layer you can divide the modifications into a load order and group them according their function for clarity and knowledge capture.</div><div><br></div><div>Fourthly you release different versions of the image for different purposes, e.g. "base-dev" as the starting point for most kernel innovators such as yourself. "~kph/stable" for the intregration and ~nice/stable for your completed innovationsdemonstration of my chosen completed innovations, and "~whoever/unstable" for the rest.</div><div><br></div><div>=</div><div>In our old bob process this was organised as a set of named tasks, in an order calculated from implicit and explicit dependencies. So the essential fixes task was loaded first, followed by package upgrades etc and at the end deprecated methods were removed, the verision number set and the image cleanedUp and saved. </div><div><br></div><div>My new process "grow", we forget using dependencies and instead use a semi-rigid framework which gives us a fixed load order.</div><div><br></div><div>We split the image vertically by defining slices of Kernel (e.g. Mutex is a discrete slice), and System is divided into packages.</div><div><br></div><div>Horizontally we have up to 9 layers, from 0 to 9, in which 0-3 would be for basic core/kernel image use, and for example, seaside would be loaded at somewhere around level 4/5.</div><div><br></div><div>Within each layer (particularly the lower layers) there are 12/13 ordered load phases. So at layer 0, the lowest level in the kernel, the first phase is the bootstrap phase.</div><div><br></div><div>The bootstrap always loads the essential code loading tools, and absolutely essential fixes in a primitive manner in the image commandline startUp script. This is essential because the code loading tools can never reliably load the code loading tools.</div><div><br></div><div>The phases are applied in alphabetical order, in layer 0 first, then layer 1 then layer 2 etc.</div><div><br></div><div>1 #bootstrap - load code loading tools (layer 0 only)</div><div>2 #fixes - fix actual broken stuff</div><div>3 #installs - install of packaged code slices</div><div>4 #moves - refactorings</div><div>5 #newapi - additions to the base api</div><div>6 #packages - install of packaged code packages (e.g. MCZ)</div><div>7 #patches - patches to packages above for this context.</div><div>8 #parity - fixes providing code parity between forks, that might be needed by the package.</div><div>9 #preferences - code which sets things up the way you like it</div><div>10 #tests - load tests from a package</div><div>11 #tidy - (re)organise things to your preference</div><div>12 #unload - remove things</div><div>13 #zed - a finalization phase.</div><div><br></div><div>So with an architecture in place you use it to define roles and responsibilities, and boundaries to make the problem manageable. Sure I agree, in layer 0, things will need to be hand crafted and bespoke to that image. However even within this layer you can see what is a fix for a bug (#fix) what is a refactoring (#move) that should not change functionality, and what is an attempt to provide a #newapi or api parity between forks.</div><div><br></div><div>If you are writing a bug fix, you can address that fix to the virtually untouched release image by publishing it as a <project: 'MyFixes' level: 0 series: #fix item: 1> e.g. </div><div><br></div><div>If you are adding core #newapi calls, you know you are doing so to the basic image before any add on packages are loaded at this level.</div><div><br></div><div>But by the time you get to layer 3, there are three layers of stuff under you that can provide your packages some commonalty of api across forks. "Grease" would be welcome at layer 2 / 3.</div><div><br></div><div>In practice, we want to deliver a base image for people to use, this image is called "base-dev", and it consists of two main parts, the fork specific part, and the common part.</div><div><br></div><div>base-dev/Kernel &</div><div>base-common/Kernel-common</div><div><br></div><div>So the bootstrap script fed to the starting image, can be made up of code that is either bespoke to a fork, or common to all forks, or both. </div><div><br></div><div>There is a cuis/base-dev, a squeak/base-dev and a pharo/base-dev. The bootstrap for all three is assembled from code that is common to all three images:</div><div><br></div><div>grow/base-common/Kernel-common/#0--bootstrap</div><div><br></div><div><div>and code that is specific to all three images</div><div><br></div></div><div>cuis/base-dev/Kernel/#0--bootstrap</div><div><div>squeak/base-dev/Kernel/#0--bootstrap</div><div><div>pharo/base-dev/Kernel/#0--bootstrap</div><div><br></div><div>So right from the initial bootstrap script, we have common code loading tools across all forks, and we are free to innovate those tools in any way we wish. We also have one of the first fixes also included in the bootstrap is the new SmalltalkIMage/Smalltalk dividing scheme - #globals #commandLine #vm #organization #query #changes etc.</div><div><br></div><div>base-dev provides enough commonality for the import and export code to work supporting the same development process on all forks. </div><div><br></div><div>Keith</div><div> </div></div></div></body></html>