> Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 
> 1.3 and it works.  I got ashamed by the amount of options in the menu, but I 
> managed to find how to load a configuration and a version, jeje.

I currently suspended my work on the browser. Unfortunately, I do not have much 
resources to allocate on it right now.

Alexandre

> 
> Cheers,
> Guille
> 
> On Sun, Jun 19, 2011 at 7:02 AM, Stéphane Ducasse <[email protected]> 
> wrote:
> 
> On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote:
> 
> > Hi,
> >
> > I think that the best idea is to have one   image for the system developers 
> > and end-users (for example, I almost never used full Pharo so it lost one 
> > tester). On the other hand we should continue with the modularization to 
> > allow to generate headless kernel image, gopher image, basic morphic image 
> > etc. on the request with bootstrapping. To have smallest possible image is 
> > not the main goal of the effort around PharoKernel. The main goal is to 
> > have beauty modular system where all dependencies all described well and 
> > packages can be  easily loaded and unloaded. The buildserver can generate 
> > all the set of images for special purposes so it will be more natural then 
> > now when we have two main images.
> 
> Yes yes yes but :) we should have a set of tools that are working together 
> and we should not be responsible of making sure that all the possible 
> combination work.
> I would like to get a process (as I mentioned in the other mail)
>        seed + MetacelloSpec + modification => seed' + MetacelloSpec'
> 
>        and that we are able to build hudson that takes
>                aSeed + a spec
>                        => run all the tests + run all the quality check
> 
> Right now we have
>        seed + list of package + modification => seed' + list of package'
> 
>        and we get in trouble when we modify seed parts that influence 
> external package
> 
> so what we want is to have
>        seed + metacello = the minimal tools that we need to be efficient 
> modifying seed
>                for me
>                        OB Engine
>                        Shout
>                        O/Ecompletion
> 
> Stef
> 
> 
> >
> > -- Pavel
> >
> >
> >
> > 18.6.2011 v 22:29, Guillermo Polito <[email protected]>:
> >
> >> Hi Stef!
> >>
> >> do you mean integrating all them in the Core?  Or maybe follow Markus' 
> >> idea of having just one image?  Maybe that's an important discussion to 
> >> have too :).
> >> I can give a hand for the repository stuff.  Should we replicate 
> >> repositories + metacello configs in order to be able to freeze them, isn't 
> >> it?
> >>
> >> Guille
> >>
> >> On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse 
> >> <[email protected]> wrote:
> >> Hi guys
> >>
> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that 
> >> we have only one single image.
> >>
> >> - load FileSystem
> >>        -> so that we can start to integrate and improve the fileSystem API
> >>
> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what 
> >> should be changed for RPackage to work
> >>
> >> - Ring
> >>        -> so that we can start to integrate it
> >>
> >> - Fuel
> >>        -> so that we can deprecate SmartRefStream (there may be a problem 
> >> with mcz (not sure)).
> >>
> >> - I want Opal in 1.4 too.
> >>
> >> - continue to remove StringHolder hierarchy
> >>
> >> - Morphic improvements
> >>
> >> Comments are welcomed.
> >>
> >> Stef
> >>
> >>
> >>
> 
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply via email to