No, it was not obvious. Even upon rereading, it doesn't seem like you're conceding that your statement that the process "can only build a monolithic image" is mistaken... it seems like you're trying to change the subject.
Josh,
You are correct I am not conceding the point, that you can only build a monolithic image. Could you build an image with the same contents as cuis using this trunk process, I don't think so. Could you maintain and build images based on cuis using this process, again no.
The community has been asking for a kernel minimal image for years, I think it is somewhat short-sighted to propose a development process that cannot actually fulfil the goal.
I never claimed that the trunk process is necessary for package unloading. You're the one who claimed that the trunk process can only build a monolithic image, and I debunked it with a counter- example.
Monolithic image, to me means, an image in which the code loading tools, the compiler, the UI, the transcript etc are all tied in extricably together and will never part.
Basically you are not able to offer anything fundamentally different from what has gone before,
In terms of unloading packages, maybe not (are you now admitting that real progress has been made in that regard?). But in terms of pace of development, obviously so.
Pace of development is no different. If Andreas had said in his original email, "Lets all get cracking on using Keith's stuff that he is documenting for us in the screen casts he released yesterday", then the pace of development would be identical. He didn't instead he said, "hey everyone I knocked this up trunk thing up over a weekend lets all pile in".
Alternatively if Andreas had said, "we now have the test and integration server to integrate new initiatives, so how about proposing some new initiatives, and get cracking on them, now you can be assured that they will be integrated in your allocated slot in the process." then pace would have been much faster, because everyone's contributions would be testable, and usable. Whereas for example if I contribute the message eating Null to trunk, I bet you a tenner Andreas will take it out again.
I didn't pick a slow development process on purpose to thwart people contributing. I didn't ask for direct contributions because we already had about 200 ready to load automatically from mantis thanks to Mr Cellier. In bob 3.11 the image was already tracking mantis, so all you had to do to make a contribution was to switch the status of the fix to "testing" in mantis, and it would be integrated in the next build.
The Bob based process, asks people to work on initiatives in their own development area, and hook the results of those initiatives into a continuous integration and testing process which produces an alpha image. This would arguably be faster, because you wouldn't have people treading on each others toes. Secondly you wouldn't have to integrate anything into the release image that wasn't 100% complete and tested. Thirdly your image is regression tested against all packages that use it, AND there is a mechanism for fixing broken packages and feeding the fixes back to their maintainers. The bob process was not just maintaining the image, it was also able to contribute to maintaining the entire squeak code base. How else would I be able to plan to eradicate FileDirectory.
regards
Keith