On Mar 3, 2012, at 12:03 PM, Tudor Girba wrote:
Hi,
I did not manage to explain myself, so let me try again with a longer email.
We all want to get to a small kernel. To get there, we should have a process that makes the progress possible in small increments. At this point, I would just be interested in putting in place a simple job that takes a seed image, and builds the image in which the core team works in.
As far as I understood, the only reason why we now have a single image is that the old Core image had poor tools, and building the Distribution was long. However, now, you do not have RB in there anymore. Removing RB was the right decision, because it means it can evolve rather independently. This also means that to do your work you would benefit from another image.
So, the simplest thing at this point, would be to start with just making the current image to be the seed and build another one with RB (and maybe Nautilus?) inside where you do your work. And then we try to see how it goes in terms your process. If it works Ok, we can start pulling out other packages.
For example, currently, there are at least two other parts that are not required to be in the seed image: AST and Filesystem. Of course, when OPAL will arrive, the AST will have to go in the seed image, but until then, it does not have to. The same with Filesystem: at this moment, it does not have to be in.
One thing that we need to watch for though is the process of including something in the Distribution. The old Dev image failed because the policy was one of "it looks interesting -> it should be in". Instead, the Distribution should be focused on providing a small set of extras that make development better.
In the end, the goal is not to come up with the kernel now, but it would be to have the infrastructure and process in place that enables us to remove things from the seed image gradually, and still get the core team to have a good toolset.
Would that be Ok?
What we need: -> One Artefact of release. *This is Pharo* (and yes, there is a small core somewhere, but that's for specialists) - The goal in that is to have everything just once. Not a "crapy X for the Core, but everyone uses Y". - No need to manage bugs for Full and Core differently - Stable. No "Dev now is different and I don't know why, nobody changed anything" (as happend with 1.3, again...) (stable in the sense: two builds of the same version should not magically be different) -> The development happens in that one release. Developers and integrators can just use that. No thinking. -> The way to commit is the same. What killed me in the Dev image approach is that it was different and difficult *in addtion* to a difficult and boring aproach for the core. (e.g. editing Metacello config by hand for every trivial change.. and breaking something every time). -> I can press "update system to latest" to update the image, no need to always download a fresh image for every trivial change. -- Marcus Denker -- http://marcusdenker.de