Jerome Peace wrote:
> The useful part of Edgar's point was that the 3.11 folder on the ftp site sits empty.
>   
Please give me a bit of a break, my mother died in March and the person
that I am a full time carer for, became elective mute for 2 months, and
has been in hospital for  3 months. I also have a day job, and haven't
got much done on the actual 3.11 in 6 months.

In actual fact I have only spent a couple of non-spare weekends on the
actual final form of the 3.11 building bit. That is the smallest part of
the 3.11 effort!

It's a bit soon to be asking for artefacts after 2 weekends work.
Perhaps 3? Having said that instructions on building 3.11 images were
published on the releases list, months ago (September I think it was),
and those scripts have been around since January last year.

There are also products out there you can look at. MC1.5, MC1.6,
Sake/Packages, Logging.

As I said before there is not huge demand for a new release of the
kernel instantly. There is huge demand for things like
LevelPlayingField, and Sake/Packages and .... there is plenty of pent up
demand for Bob the Builder which I have promised asap.
> I personally do not want to have to understand what is on the pbwiki or to navigate keith's new ways of doing things in order to play and test out a new squeak image.
>
> What unsettles me at the moment is that two very powerful programmers are taking 3.11 in some very new directions relative to what the community is used to.
>   
The alternative was officially nothing. I piped up when the board were
considering cancelling 3.11

So anything is better than nothing, perhaps?
> While I have a great respect in Matthew's judgment and ability to explain what he is doing, I have found from experience that Keith's notions are more of a gamble.
>   
So far, I am quite pleased to say that everything I have put my hand to
has worked really well.

But this comment indicates to me that you really dont "get it" yet.

The whole deal with this 3.11 project is not about delivering an image,
its about addressing a need, through putting a philosophy into practice
across the board. The 3.11 goal is to showcase the tools that make that
philosophy possible. While the tools are not ready there is no 3.11
(fortunately the tools are getting there and there will be a 3.11)

The need is definitely there, and the philosophy aiming to meet that
need has been operating well for almost a year now. That's not a gamble
at all, its already happening.

Edgar has delivered image after image, but does that help anyone in the
long run really. It  doesn't help me. I have production code and I don't
have time to spend a month moving it form one image to another manually,
without any tools to help, broken MC, broken Universes etc. It doesnt
help us move forward in the future to something like Morphic 3.0, or COG
for which atomic loading is likely to be essential.

Real World Example:

As an example, Gjallar was working in 3.8, there is no technical
compelling reason to move the huge code base over to 3.10. It doesn't
offer any must have new features. The only reason for moving is to be
able to keep up for the sake of it. So into this situation comes
Installer, Gjallar migrates to use Installer for its build scripts
(July2007). Once Installer is used, the build script can be run in 3.7,
3.8, 3.9, 3.10, Sophie, Croquet or Etoys. Installer proves the common
ground that is essential to move forward, even though that move didn't
take place for almost a year, the Gjallar team knew that they were no
longer a fork, because they had the tools to make keeping up possible
and straight forward.

So did Gjallar move to 3.10 because of the 3.10 image features, or
because Installer and LevelPlayingField helped make it a smooth
transition?  Gjallar is a fork no more. Which of 3.10/Installer is
really contributing most to moving the community forward? I would say
that Installer is doing a damn fine job for a little tool.

The  philosophy of which I speak is one of supporting everyone who is
using squeak, in every different image and fork, so that they can move
forward, hopefully on a convergent path.

Edgar still looks for the forks to agree on a common kernel, his
approach expects the other forks to follow him. What is actually
happening is more and more divergence, and if that continues squeak
3.10+ will get less and less patronage as the community spreads out more
and more.

In contrast our philosophy accepts that there are forks, and is pleased
that lots of interesting work is being done in diverse places. But we
can afford to hold off on the run of the mill process of adding 100 or
so minor fixes, preferring instead to build more common ground.

So... the 3.11 release team in recent months has worked on Installer,
Atomic Loading for MC, Sake, Sake/Packages, SUnit, Files support for MC,
Sake-Scheduler, Mantis (squeak code for using mantis data), Rio, and
Bob. All for the purposes of moving the whole community (and in
particular my paid work) forward.

Just because one possible deliverable is a 3.11 image, the image is not
the most important thing. The important thing is the amount of common
ground achieved/achievable.

Example:

Rather than maintain 10 different CollectionsTests, it would be good to
maintain just one uber-CollectionsTest package. This would be helpful in
order for the community to maintain parity with API's in all forks.

So if I am a squeak 3.10 user and I add a feature to Collections with a
test. When a 3.8 user loads the latest and greatest test cases, my new
test will break in his image, but work in mine, giving him "non green"
status.

So SUnit needs to be able to understand that it is being used in several
images, and tests need to be marked if there are any anomalies between
target image/platform/vm etc.

I wrote the code to achieve this 2 years and 3+ months ago. The code in
itself is no use, without someone putting the uberCollectionTests vision
into practice, and you dont need a 3.11 image to do it. However the 3.11
effort is aiming to showcase the collection of tools that give us this
common ground.

The alternative earlier in 2008 was that Squeak3.11 would not have gone
ahead, and my effort on improving SUnit 2 years ago would have been
wasted entirely. Thats why I took this on.

The important thing is that all of the contributions to that 3.11 are
also available to all other image users. So you don't have to wait for a
3.11 image to partake of the new wine.

Its not really a gamble its a coherent strategy to implement what Goran
had as a vision, multiple update streams, but in a different form.
Different experts can contribute different tasks managed in Monticello.
> Keith is a gatekeeper for ideas from other communities like Ruby. He is powerfully fast. And he is focused on core changes that bring with them a lot of power and ease.
>   
I dont know about that, I have been smalltalking full time for much of
14 years, rubying for about 9 months total over 8 years.

Sake was Brian's idea.
> On the other hand, I am afraid I have a great trouble trying to wade into his explanations. They get (for me) too technical, too quickly. They leave me scratching my head as to what the big simple picture is all about. So I am left with no easy way of understanding or judging his work. That in itself makes me uneasy.
>
> He and I have discussed this in private via emails.
>
>   
> My other concern about this release is that it is actually a development project.
Correct it is a development project to create tools for making releases
when the previous teams have complained about the tools.
>  The code is being written concurrent with the release. Andreas made a suggestion that each release should harvest what is already available in order to reduce risk.
Risk of what? at one point 3.11 wasnt going to happen at all, anything
more is a bonus.
>  The plan for this release (and the talents of the release team) seem to be more state-of-the-not-quite-invented-art. This is a risk to the stability and timeline of the release.
>   
Basic programming principles, three variables,
time/functionality/quality. The functionality required is essentially
fixed. The quality has to be high, but requires the test server
functionality, so time is the the variable. Its ready when its ready.

Once the tools are complete we switch to a completely different
workflow, timeboxed releases, all tests green etc etc etc.
> 3.9 took two years and was release with so much stuff, integration bugs were almost assured. Users ran into some good ones.
>
> 3.10.2 took a year even though it was modest in scope. It too was released with some very obvious bugs that hadn't been in 3.9. The main learning that came out of it was how brittle a release became when it was dependent on MC for development.
>
> The current 3.11 release is an effort to find a viable way to maintain a release again. But where is the project now? And where are the (understandable) artifacts?
The explicit 3.11 part of project was effectively delayed for 6 months
due to my personal reasons and work commitments. So please be gentle.
> As a bug tracker, my experience warns me of trouble when big steps are taken w/o feedback. So I am wondering if Edgar's point can't be addressed.
> Could we get an alpha image of the current stable and unstable versions of 3.11 onto the ftp site?
>   
Its on its way, and there have been instructions available on the
release mailing list on how to build an image yourself for several months.
> This would serve as a check on backward compatibility and usability for 3.11. And give the rest of us something to do.
>   
Have you joined the release list?
> Yours in curiosity and service, --Jerome Peace
>   

Dont Panic

Keith