[squeak-dev] Re: [Cuis] Cuis
keith_hodges at yahoo.co.uk
Fri Jan 22 02:17:09 UTC 2010
> 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.
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-
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
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
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
More information about the Squeak-dev