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
