On 13 March 2010 04:11, keith <keith_hodges at yahoo.co.uk> wrote:
> 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.
>

This is not about charisma, i think. It is about how you presenting your ideas.
Juan usually says: hey, here is a new Cuis ready to play with.
He never going into a deep details, what is his plans or what he's
going to do, still some of his ideas took and ported to other forks.
I think people interested in his stuff, because he giving away thing,
which everyone knows how to deal with:
 image.


>> 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'd start from an abstract source-management layer, so then i could
use different backends - file system, network,
image etc. Just an idea, given away under MIT license :)

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

The list of goals is good. And i wish you success.

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

Keith, have you discussed among smalltalkers your idea of keeping a
meta-information in pragmas,
instead of full pledged smalltalk objects (class, package, changeset etc)?
Again, to what degree you expect that given idea will be wellcomed
among smalltalkers (of many forks)?
Do you see, what i'm trying to say?
If you trying to sell something, you should know that it is exactly
the thing, everyone wants to buy :)

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

Yes, because most of the times, people don't need a deep technical
details and understanding in order to use something.
You can use computer without knowing what transistor is.

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


-- 
Best regards,
Igor Stasenko AKA sig.