<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="font-size: 16px; ">I see what you're saying.</div><div style="font-size: 16px; "><br></div><div style="font-size: 16px; ">I started to write responses to a couple of other posts, but I realize that there are still things that I don't understand about your proposal. Please continue to help me understand.</div><div style="font-size: 16px; "><br></div><div style="font-size: 16px; ">Let's imagine that 3.10.2 just came out, and that we have your process in place. I'm assuming that we can equate 3.10.2 to A. The important part that I'm missing is that I don't know the time interval between A and A.2. Is it on the order of a week or two, or 6 months? Once I know the answer, I'll have more to say.</div></div></blockquote><div style="font-size: 16px; "><br></div><span class="Apple-style-span" style="font-size: 16px; ">Given that once A is out (a fixed point), work begins on migrating innovations in progress, to load into A, and fixes not yet integrated, to test them against A.</span></div><div style="font-size: 16px; "><br></div><div style="font-size: 16px; ">The automated script generating and testing "Ax-stable-alpha-test" image candidates, runs every (?) time a bug fix status is changed from "testing" to "passed" in mantis. So as soon as A is released, this script is switched to start loading and testing fixes against it.</div><div style="font-size: 16px; "><br></div><div style="font-size: 16px; "><div>Practically speaking, allowing for a 2 week break after the release to let the dust settle, a serious go at producing the next release candidate A.2-stable-beta should be made within a month and leaving a couple of weeks to finalise things. You are looking at a new fully tested release A2-stable (fixed point) every 4-6 weeks.</div><div><br></div></div><div style="font-size: 16px; "><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Also, you often refer to the codebase that you're developing against A that you will eventually want to move forward to whatever the latest is (maybe A.2, or maybe A.10). How often do you envision porting your packages forward to the latest? Every week or two? Every 6 months? Does it depend on the specific developer/codebase?</div></div></blockquote><div><br></div><div>There are two builds happening simultaneously, A+1-unstable, (unstable builds on an image loading mantis fixes status "testing") and A+1-stable (builds on fixes status "passed"), and you can add your own, like A+1-stable+withnamespaces, A+1-unstable+closures etc.</div><div><br></div><div>So package developers can see what is coming, by checking the results of the "developer" image, or the "web" image that is built upon A+1-unstable.</div><div><br></div><div>The new A2.3.4 etc, are automatically used as a basis for building all derived images, such as the developer image, the web image, fun, and my own working image build etc. So it is quickly obvious when a package is failing to keep up, or a kernel patch is breaking things for everyone.</div><div><br></div><div>Given that the packages are at A.x-1, when you release A.x, for the tests to pass, you just need a version of the package that is compatible with two releases, the newest and the previous one to ensure a continuous migration path for everyone.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>(BTW, I'm curious, can you cite an example of a successful project that uses this approach? If you can't, that doesn't automatically disqualify your idea (someone has to be first), but I'm still curious. Please, just a short yes or no, with no loss-of-face or giving-up-ground implied in a negative answer).</div></div></blockquote><div> </div><div>It's what I do every time I build an image to use, I have been using this process for several years, because squeak releases are few and far between.</div><div><br></div><div>Task 1. download the old release (A.0)</div><div>Task 2. load the tested stable kernel fixes that I know I need. (Either from mantis, by number, or from a MC package that I use to maintain them, "Kernel-Extensions")</div><div>Task 3. upgrade all the externally managed packages that the release has out of date versions of.</div><div>Task 4. load all the packages that provide my basic tools</div><div><div>Task 5. unload a few things.</div></div><div>Task 6. reorganise stuff to make things a bit tidier.</div><div>Task 7. (optionally) Save everything to monticello.</div><div><br></div><div>This was automated, and I save my actual working base image (A.1) that then build my product on, starting with the developer tools (optional), seaside, pier, rio, beach and magma.</div><div><br></div><div>Given that this process, is how I move an ageing release to be an image that is good enough to actually start working with. And I do this every month or two, and for every new client. I figured that the same process would be able to provide the monthly iterations, such that A.1 actually gets saved as 3.11.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>You should cut people some slack,</div></div></blockquote><div style="font-size: 16px; "><br></div>Sorry but I was on my holiday when this all kicked off. Where was the slack for me?<br><div style="font-size: 16px; "><br></div><div style="font-size: 16px; ">This discussion all happened 3 years ago amongst members of the release team, and in the preparation of the proposal with the board. For 3.10 Everyone that was interested in the release was on the release-team list. Very few discussions were held on squeak-dev. </div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> because you have been anything but consistent on this point over the past months. You're focusing on the abstract principles now, but at other times you've said that Bob/Mantis is good to go, and that we should start using it immediately.</div></div></blockquote><div><br></div><div>Mantis, has been used for collating fixes for years. It is good to go. Automated loading of mantis fixes is provided by InstallerMantis. You can do it yourself using code along the lines of (I dont have an image open)</div><div><br></div><div>(Installer mantis allBugs select: [ :ea | ea status = "Testing" ]) do: #ensureFix.</div><div><br></div><div>We already had more fixes marked for integration than I could handle, in a single iteration. Effort would be better served packaging other innovations ready to be cleanly loadable into 3.10, such as closures. </div><div><br></div><div>I thought the board understood the abstract principles, since we discussed them in person with some people, and we had to write a proposal etc.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Having said that, I'm comfortable with agreeing that criticisms of Mantis/Bob (i.e. the current concrete implementation) </div></div></blockquote><div style="font-size: 16px; "><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>are out-of-bounds while we consider the abstract principles involved (of course, if we get to the point where you convince the community that you're correct in principle, then criticizing Mantis/Bob is back on the table as we decide *how* to implement your ideas).</div><div><div><br></div>OK, gotcha. Are we ready to proceed? (did I manage to avoid saying anything that you violently disagree with?)</div></div></blockquote></div><br style="font-size: 16px; "><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 16px;">you did ok.... would you like to run for the Board?</span></font></div><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 16px;"><br></span></font></div><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 16px;">Keith</span></font></div><div><font class="Apple-style-span" size="4"><span class="Apple-style-span" style="font-size: 16px;"><br></span></font></div></body></html>