Hi Igor, thanks for having a look.

It is early days.

> Keith,
> trunk process is not a silver bullet.
> You should think in a way how to sell your ideas,

I don't see the point, the community is closed to new ideas. Getting  
an idea adopted, depends more on who sends the email to squeak-dev  
than the merits of the idea. Apparently I don't have enough charisma.

> instead of keep bashing trunk.
> Telling that trunk is bad, doesn't makes your ideas better.

correct, any idea would be better, any idea that doesn't involve a  
moving target.

> If you want to propose an evolutionary path, with easy migration of
> trunk-alike process to something else,
> which removes some (or most) of its shortcomings, please do so.
> For example. You presented some ideas lately.
> I read it briefly, and i don't feel much convinced that it would be
> cool to use it.

The goal is to work with a kernel image, so what does a kernel image  
not have. For a start it doesn't have tools like MC. So your starting  
point has to be from the moment you launch an image. This has always  
been the case.

> First, you introducing a dependency from external tools, like bazaar ,

There is no great dependency on external tools, that is also by  
design. "Grow" is a utility I wrote to help you manage which vm goes  
with which image etc, you can do that yourself if you want to.

The external tools are whatever you choose to use for sharing code in  
file form, bazaar happens to be an ok solution. I also quite liked  
some of the others. Some people might prefer git (bazaar is compatible  
with git), ftp, or a shared file-system under fuse/smb or throwing zip  
files around in email lists.

The key point is to remove any dependency on stuff like squeaksource  
or mantis, that is not under your control, and to be able to work  
entirely offline. This is the main selling point of gofer over  
installer that I understand, since Stef wants to work on the train.

> and using a file system for organizing the source code.

Cuis doesn't have http support, so where else are you going to put the  
code?

I am not trying to be cool, I am trying to make "the simplest thing  
which could possibly work" given the constraints of the goals, the  
goals are...

1 Work with any image/fork as a starting point.
2 Apply a deterministic process for integration of loads of stuff
3. Be able to work entirely offline
4. Minimal dependencies on any stuff in the image, (because you don't  
know what you are going to get)
5. Minimal tools in the image, one class preferably (with  
InstallSeries, and System-Imports = approximately 6 classes in a  
bootstrap)
6. Share stuff between (i.e steal stuff from) forks and level off apis  
if possible
7. Load seaside magma pier magritte scriptaculous, and 40+ other  
packages in a deterministic way in any image or any smalltalk,  
including ST/X.

Considering I can do all of this with my 6 classes, I am quite happy.

If it works with ST/X I will be sorely tempted to go back and use it  
again as my main development environment.

Additional goals,

8) to support a deployed image with updates

> Next, from your description, i see there are many technical
> details/moves in order to get into the field and start playing.

Watch this space, I will produce a wizard at some point. There is no  
point in producing my producing a wizard until I know what I am wizzing.
We have the tools now to make a wizard, but it took a week to write  
them. Please bear in mind this process has only been around for three  
weeks.

> What i would prefer is as simple, as trunk offers:
> - push that button (or file-in that code) and you're in

How about download an image and you are in.

Download the image base-dev.image from

bzr checkout --lightweight http://www.launchpad.net/cuis/base-dev-images

Write your changes, define in a class method somewhere the slice you  
want to export.

thisFix

	<slice:  'MyFix' version: '1.0'>
	<project: 'Igors-Project' level: 0 series: #fix item: 1 >

"This is my great fix"

	^ [ :pkg |

		pkg stampComment.
		plg class: SomeClass selectors: #(#somethingChanged #andThisChanged)
	]

Then run

Export doExport

and all the slices will be exported to the file system. Find the file  
that was exported and email it to me or something, or poke your  
project into a bazaar repo and let others download it.

> A simplicity, as to me, is a key here.

You are hiding a lot of complexity behind that "updates" button.

> We should evolve gradually
> making a simple steps one after another. So, there will be no too much
> oppression from community, because if we do things right, its easy to
> understand where improvement lies and at each step
> we could analyze and then decide what next step should be and in  
> what direction.
> But if you making too big steps, expect that there's many who can't
> cope up with you , and hence will refuse to follow your path, simply
> because it is uncertain for them what will be direct benefits, because
> you trying to sell a swiss-knife as a screwdriver.

I am trying to do what we said we would do, this was the essence of  
our statements:

"We will not produce another fork of squeak, we will produce a process  
which enables all innovations to be used by all forks, thus helping  
forks to converge not diverge."

With my "grow" process I can define a slice which exports the compiler  
from trunk as a changeset or 10.

In cuis the file import tools will be able to change the name of  
classes on import, so, the compiler can be loaded as Compiler2, and  
switched in by changing

Smalltalk>>actualCompilerClass ^ Compiler2

sold yet?

regards

Keith