Brave New World

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.

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?

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

You should cut people some slack,

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.

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

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.

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.

... and thanks again.

One thing that strikes me about this is that it is agnostic about how the fixed-point images are built.

... and thanks again.

One thing that strikes me about this is that it is agnostic about how the fixed-point images are built.

The fixed point images need to be built, by a process which applies to the previous fixed point.

So that a fork which was made from the previous fixed point, can cherry pick from, and apply that process too.

The more that separate forks pick ideas from other forks, the more they have in common.

Basically to use the knowledge that is in trunk, you will have to analyse it and sort it into separate useful innovations and ideas, and publish them as separate changesets.

Ironically, most of those innovations could have started of as separate changesets in the first place. Am I making sense?

Keith

I contend that for the latter, it does not matter how the fixed-point image was created, just that you continuously build and test your application against frequent releases, and work with the community to quickly fix any compatibility issues that arise.  Isn't this true?

Thanks,

Josh

I contend that for the latter, it does not matter how the fixed-point image was created, just that you continuously build and test your application against frequent releases, and work with the community to quickly fix any compatibility issues that arise.  Isn't this true?

Thanks,

Josh

It would be lovely, but it just doesn't happen. Ask etoys, cobalt, sophie, gjallar. They all started large projects and did not find the time or the effort to track subsequent squeak releases. One problem is that individual releases were too revolutionary for many, trying to to do much in one go,  this can be helped by release early and often.

More than that the release teams didn't take any responsibility for the migration path.  (e.g. Smalltalk -> SmalltalkImage)

This same problem occurs at a package level too. I am stuck about 150 (or more now) revisions behind in Pier, because my modifications to pier (which I do keep in a separate package), are effectively (but accidentally) a fork. In trying to solve the problem, the more I see the tools, i.e. Monticello as part of the problem. However at present the solution alludes me.

K.