From protest to proposal (Was: Re: [squeak-dev] [Election] ...is
soon upon us! Last day info)
keith_hodges at yahoo.co.uk
Sat Mar 13 02:11:19 UTC 2010
Hi Igor, thanks for having a look.
It is early days.
> 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
> 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
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
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
6. Share stuff between (i.e steal stuff from) forks and level off apis
7. Load seaside magma pier magritte scriptaculous, and 40+ other
packages in a deterministic way in any image or any smalltalk,
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.
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
> 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.
<slice: 'MyFix' version: '1.0'>
<project: 'Igors-Project' level: 0 series: #fix item: 1 >
"This is my great fix"
^ [ :pkg |
plg class: SomeClass selectors: #(#somethingChanged #andThisChanged)
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
"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
More information about the Squeak-dev