[squeak-dev] Re: [Cuis] Cuis

keith 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.

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



More information about the Squeak-dev mailing list