[squeak-dev] Notes from Release meeting 5 are finally out

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Notes from Release meeting 5 are finally out

Tapple Gao
I finally compiled the notes from the last release meeting,
which was slightly over a month ago:

http://installer.pbwiki.org/MeetingNotes005

The meeting was the first discussion about what should be in
3.11 and who will be doing and organizing it.

I will put this into a more central web page soon.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Notes from Release meeting 5 are finally out

Igor Stasenko
2008/5/18 Matthew Fulmer <[hidden email]>:

> I finally compiled the notes from the last release meeting,
> which was slightly over a month ago:
>
> http://installer.pbwiki.org/MeetingNotes005
>
> The meeting was the first discussion about what should be in
> 3.11 and who will be doing and organizing it.
>
> I will put this into a more central web page soon.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
>

# Major changes

    * KernelImage: Pavel and Edgar
    * Build system: Keith, Matthew, and Ken
          o Definitely involves Installer
          o Would be nice to involve DeltaStreams if/when it is ready

Last time i speak with Egar, he don't likes the idea of using
Installer (or maybe i didn't understood well, at which stages he wont
use it, which possible also :) ).

My 2 cents about making things modular:
HAVING SMALLER IMAGE DOESN'T MEANS MODULAR IMAGE.
Example: you can unload traits (thanks to Matthew), but can't load
them back, or iterate load/unload multiple times :)

I'm okay with idea of having smaller image as a base, which means that
it easier to maintain by small team and delegate different parts to be
handled by other teams.
But we all need to work in environment having at least basic set of
tools for coding & debugging. And this definitely requires UI.
And UI currently can't be loaded/unloaded by will. So, you need to
develop your project in dev-image, which having all these tools, but
for deployment use different one, where morphic, or other dev-related
packages not installed.

So, i see that in 3.11 we should pay attention how make things more
modular: by introducing automated scripts which can unload & load
things back automatically.
And this is where such Installed can be very helpful:

10 timesRepeat: [ Installer install: 'Morphic'. Installer uninstall: 'Morphic' ]

Edgar having different view on this:
use minimal base kernel image, and then build new image, from a
scratch by loading different packages.
It easier to use (since we need to support for loading code), but not
truly modular, since you really unable to unload things , when you
don't  need them.

My vision, that initially, 3.11 should be based on 3.10 (to support a
development continuity) and using automated and well-tested scripts,
strip image to minimal kernel.
A received artifact should support then loading things back (Morphic
e.t.c.), as well, as unloading them again.
That's what i call 'modular' :)

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Notes from Release meeting 5 are finally out

Pavel Krivanek
Hi Igor,

do you know the KernelImage? Because it is the process you are talking about. It's the set of images where you have a small kernel.image that can load packages through morphicCore.image  up to etoys.image (with the code base very close to standard 3.10 image) and you can shrink it back down to kernel.image and repeat the process again. The current limitation is that you should use morphicCore.image as the starting point of shrinking because upper packages do not have cleaned unloading process yet.

http://www.squeaksource.com/KernelImage.html
http://squeak.cz/public/pub/KernelImage/current/

Cheers,
-- Pavel

On Sun, May 18, 2008 at 10:14 PM, Igor Stasenko <[hidden email]> wrote:
2008/5/18 Matthew Fulmer <[hidden email]>:
> I finally compiled the notes from the last release meeting,
> which was slightly over a month ago:
>
> http://installer.pbwiki.org/MeetingNotes005
>
> The meeting was the first discussion about what should be in
> 3.11 and who will be doing and organizing it.
>
> I will put this into a more central web page soon.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
>

# Major changes

   * KernelImage: Pavel and Edgar
   * Build system: Keith, Matthew, and Ken
         o Definitely involves Installer
         o Would be nice to involve DeltaStreams if/when it is ready

Last time i speak with Egar, he don't likes the idea of using
Installer (or maybe i didn't understood well, at which stages he wont
use it, which possible also :) ).

My 2 cents about making things modular:
HAVING SMALLER IMAGE DOESN'T MEANS MODULAR IMAGE.
Example: you can unload traits (thanks to Matthew), but can't load
them back, or iterate load/unload multiple times :)

I'm okay with idea of having smaller image as a base, which means that
it easier to maintain by small team and delegate different parts to be
handled by other teams.
But we all need to work in environment having at least basic set of
tools for coding & debugging. And this definitely requires UI.
And UI currently can't be loaded/unloaded by will. So, you need to
develop your project in dev-image, which having all these tools, but
for deployment use different one, where morphic, or other dev-related
packages not installed.

So, i see that in 3.11 we should pay attention how make things more
modular: by introducing automated scripts which can unload & load
things back automatically.
And this is where such Installed can be very helpful:

10 timesRepeat: [ Installer install: 'Morphic'. Installer uninstall: 'Morphic' ]

Edgar having different view on this:
use minimal base kernel image, and then build new image, from a
scratch by loading different packages.
It easier to use (since we need to support for loading code), but not
truly modular, since you really unable to unload things , when you
don't  need them.

My vision, that initially, 3.11 should be based on 3.10 (to support a
development continuity) and using automated and well-tested scripts,
strip image to minimal kernel.
A received artifact should support then loading things back (Morphic
e.t.c.), as well, as unloading them again.
That's what i call 'modular' :)

--
Best regards,
Igor Stasenko AKA sig.




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Notes from Release meeting 5 are finally out

keith1y
Pavel Krivanek wrote:

> Hi Igor,
>
> do you know the KernelImage? Because it is the process you are talking
> about. It's the set of images where you have a small kernel.image that
> can load packages through morphicCore.image  up to etoys.image (with
> the code base very close to standard 3.10 image) and you can shrink it
> back down to kernel.image and repeat the process again. The current
> limitation is that you should use morphicCore.image as the starting
> point of shrinking because upper packages do not have cleaned
> unloading process yet.
>
> http://www.squeaksource.com/KernelImage.html
> http://squeak.cz/public/pub/KernelImage/current/
>
> Cheers,
> -- Pavel
Just to let you know. Last time I tried KernelImage would not work on
Mac OSX

Keith


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Notes from Release meeting 5 are finally out

Igor Stasenko
In reply to this post by Pavel Krivanek
2008/5/19 Pavel Krivanek <[hidden email]>:

> Hi Igor,
>
> do you know the KernelImage? Because it is the process you are talking
> about. It's the set of images where you have a small kernel.image that can
> load packages through morphicCore.image  up to etoys.image (with the code
> base very close to standard 3.10 image) and you can shrink it back down to
> kernel.image and repeat the process again. The current limitation is that
> you should use morphicCore.image as the starting point of shrinking because
> upper packages do not have cleaned unloading process yet.
>
> http://www.squeaksource.com/KernelImage.html
> http://squeak.cz/public/pub/KernelImage/current/
>

Good, then we are not very far from each other in idea, how things
should be done :)


--
Best regards,
Igor Stasenko AKA sig.