Hi Keith,

Thanks for taking the time to answer my e-mail. Please see my comments  
and further questions below.

Am 12.07.2009 um 16:28 schrieb Keith Hodges:
> Bernhard Pieber wrote:
>> I must admit that I don't understand why these new package versions
>> are not useful for you. It's very probable that I don't understand
>> your 3.11 process well enough even though I have read most of your
>> e-mails about it.
>>
>> If I understand your process correctly it should work with different
>> images as a starting point, right? So why can't you create one of  
>> your
>> tasks which
>> 1. takes 3.10-7159-basic,
>> 2. load the latest version of MonticelloConfigurations from trunk
>> 3. MCMcmUpdater updateFromRepositories:
>> #('http://source.squeak.org/trunk' <http://source.squeak.org/trunk 
>> %27>
>> 'http://source.squeak.org/tests') <http://source.squeak.org/tests%27%29 
>> >
>> 4. continue with your envisioned 3.11 process?
> Because the fixes that will be applied have all been developed and
> submitted relative to 3.10. The packages that you update to the latest
> versions will all have been developed against 3.10.
I am not sure if I understand correctly what you mean by "developed  
against 3.10". Do you mean a certain image like Squeak3.10.2-7179- 
basic? You probably don't mean that if I want to fix or improve  
something I should always do that in a certain image, do you? I  
thought you were deemphasizing that everyone uses the same image.

> Using your method you would have to generate the new image, without  
> the
> latest of anything, or the fixes, and then wait for everyone to sift
> through the fixes and make them relative to your version, which kind  
> of
> defeats the object. It is already risky enough applying fixes en-masse
> for testing, since there may be clashes.
Interesting. So far it looked exactly like the opposite to me. Since I  
tried out the board's proposal I always stayed in the same image and  
just pressed the "load code updates" button. On the other hand I  
thought your proposed process would have me start from new images  
regularly because you said the update button was useless in that other  
thread.

Sorry, it seems my misunderstanding is even bigger than I realised. I  
am trying hard not to be dense. ;-) So, how often would you take a new  
image in your proposed process? Would Bob be one central server, or  
would everyone have his own Bob?

> If you do follow you plan, the fixes in mantis are now against some
> indeterminate version, and cant be used by existing 3.10 users in  
> their
> existing 3.10 images. This leaves production images and forks based  
> upon
> 3.10 without fixes that they can apply.
See my first question.

> Secondly the knowledge that you are putting into trunk is not  
> organised
> into separate portions, it is effectively ad-hoc. Therefore I don't  
> know
> what I am adding and what I am not. Documentation of the changes is is
> not automatically generatable,
As every package version has a comment it seems certainly possible to  
generate all the changes in trunk. What am I missing?

> and furthermore I cant publish this
> knowledge in a form that is useful to Cobalt, or any of the other  
> squeak
> forks.
>
> This leaves the Cobalt guys to plough through the history of 40+
> packages to findout what you have done. This wont happen so the forks
> wont get much closer together.
>
> Thirdly, it would be better for everyone if the same effort was put  
> into
> picking a specific project or subsystem that is worked on as an
> engineered task, plans, specs, defined interfaces etc, in such a way  
> as
> all forks could benefit.
I agree with that. I just can't see why I or someone else could not  
merge my package versions I save to source.squeak.org/trunk to say  
Pharo. It will always have to be a manual process anyway, because the  
APIs in the image are different. I am not sure if you agree with that.  
Do you?

Sorry but I am still confused. ;-)

Cheers,
Bernhard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090712/a6f7e27c/attachment.htm