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? Cheers, Doru On 3 Mar 2012, at 09:43, Marcus Denker wrote: > >>>> It's not possible to turn 1.4000 into the current one by loading packages >>>> in one step. >>>> because there are lots of objects that need to be migrated... it's a >>>> living system. >>>> >>>> There was *a lot* of manual fiddling involved, even just from one step to >>>> the next. >>> >>> but can we try and see :) >>> > > > Another question: is this really the next thing to solve? > > There are two things: > > A) Building the image from a small kernel (where all of them are > already at the same version: they in priciple fit together) > B) Updating an image version X to X+1, or even X to X + 15, as fast as > possible, with as little data as possible. > > These are two different problems... just the result is the same... and one > needs both. But B) is not "loading packages". > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > -- www.tudorgirba.com "Being happy is a matter of choice."
