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

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

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

Task 1. download the old release (A.0)
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")
Task 3. upgrade all the externally managed packages that the release  
has out of date versions of.
Task 4. load all the packages that provide my basic tools
Task 5. unload a few things.
Task 6. reorganise stuff to make things a bit tidier.
Task 7. (optionally) Save everything to monticello.

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.

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.

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

> Having said that, I'm comfortable with agreeing that criticisms of  
> Mantis/Bob (i.e. the current concrete implementation)

> 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).
>
> OK, gotcha.  Are we ready to proceed? (did I manage to avoid saying  
> anything that you violently disagree with?)

you did ok.... would you like to run for the Board?

Keith

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