On Jan 24, 2010, at 1:09 PM, keith wrote:

>> I see what you're saying.
>> 
>> 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.
>> 
>> 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.
> 
> 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.
> 
> 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.
> 
> 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.


Thanks...


> 
>> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.


... and thanks again.

One thing that strikes me about this is that it is agnostic about how the fixed-point images are built.  From the point of view of the application codebase that you are supporting, it will work  just as well (more or less) to use your scripts to automatically load/test packages into a released trunk image (assuming that the trunk images are released every couple of weeks).

I'm quite sure that this is basically true, right?  I'm also quite sure that you'll be quick to point out ways that it isn't!  Please do, I'm sure that I'm missing a thing or two.



> 
>> (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).
>  
> 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.


Thanks, I know.  I should have been more specific; I was wondering about multi-developer teams using this approach.


>> You should cut people some slack,
> 
> Sorry but I was on my holiday when this all kicked off. Where was the slack for me?
> 
> 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. 
> 
>> 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.
> 
> 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)
> 
> (Installer mantis allBugs select: [ :ea | ea status = "Testing" ]) do: #ensureFix.
> 
> 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. 
> 
> 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.


So, to reiterate, you're saying that earlier you were under the impression that the abstract principles were already understood, and that you didn't need to keep repeating them.  But more recently (perhaps especially in the last few days) it became apparent to you that people were criticizing the technology rather than the ideas?  Fair enough.  FWIW, I'm glad that you decided to be explicit that you want to talk about the principles rather than the technology... the communication seems to work much better for some reason.  

Cheers,
Josh


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100124/1f210b43/attachment.htm