<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Hi Keith,</div><div><br></div><div>Thanks for taking the time to answer my e-mail. Please see my comments and further questions below.</div><div><br></div><div>Am 12.07.2009 um 16:28 schrieb Keith Hodges:</div><blockquote type="cite"><div>Bernhard Pieber wrote:<br><blockquote type="cite">I must admit that I don't understand why these new package versions</blockquote><blockquote type="cite">are not useful for you. It's very probable that I don't understand<br></blockquote><blockquote type="cite">your 3.11 process well enough even though I have read most of your<br></blockquote><blockquote type="cite">e-mails about it.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If I understand your process correctly it should work with different<br></blockquote><blockquote type="cite">images as a starting point, right? So why can't you create one of your<br></blockquote><blockquote type="cite">tasks which<br></blockquote><blockquote type="cite">1. takes 3.10-7159-basic,<br></blockquote><blockquote type="cite">2. load the latest version of MonticelloConfigurations from trunk<br></blockquote><blockquote type="cite">3. MCMcmUpdater updateFromRepositories:<br></blockquote><blockquote type="cite">#('http://source.squeak.org/trunk' &lt;<a href="http://source.squeak.org/trunk%27">http://source.squeak.org/trunk%27</a>&gt;<br></blockquote><blockquote type="cite">'http://source.squeak.org/tests') &lt;<a href="http://source.squeak.org/tests%27%29">http://source.squeak.org/tests%27%29</a>&gt;<br></blockquote><blockquote type="cite">4. continue with your envisioned 3.11 process?<br></blockquote>Because the fixes that will be applied have all been developed and<br>submitted relative to 3.10. The packages that you update to the latest<br>versions will all have been developed against 3.10.<br></div></blockquote>I am not sure if I understand correctly what you mean by "developed against 3.10". Do you mean a<font class="Apple-style-span" color="#000000" size="3"><span class="Apple-style-span" style="background-color: transparent; font-size: 12px;">&nbsp;certain image like&nbsp;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.</span></font></div><div><br><blockquote type="cite"><div>Using your method you would have to generate the new image, without the<br>latest of anything, or the fixes, and then wait for everyone to sift<br>through the fixes and make them relative to your version, which kind of<br>defeats the object. It is already risky enough applying fixes en-masse<br>for testing, since there may be clashes.<br></div></blockquote>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.</div><div><br></div><div>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?</div><div><br><blockquote type="cite"><div>If you do follow you plan, the fixes in mantis are now against some<br>indeterminate version, and cant be used by existing 3.10 users in their<br>existing 3.10 images. This leaves production images and forks based upon<br>3.10 without fixes that they can apply.<br></div></blockquote>See&nbsp;my&nbsp;first&nbsp;question.</div><div><br><blockquote type="cite"><div>Secondly the knowledge that you are putting into trunk is not organised<br>into separate portions,&nbsp;it is effectively ad-hoc.&nbsp;Therefore I don't know</div></blockquote><blockquote type="cite"><div>what I am adding and what I am not. Documentation of the changes is is<br>not automatically generatable,</div></blockquote>As every package version has a comment it seems certainly possible to generate all the changes in trunk. What am I missing?</div><div><br><blockquote type="cite"><div>and furthermore I cant publish this<br>knowledge in a form that is useful to Cobalt, or any of the other squeak<br>forks.<br><br>This leaves the Cobalt guys to plough through the history of 40+<br>packages to findout what you have done. This wont happen so the forks<br>wont get much closer together.<br><br>Thirdly, it would be better for everyone if the same effort was put into<br>picking a specific project or subsystem that is worked on as an<br>engineered task, plans, specs, defined interfaces etc, in such a way as<br>all forks could benefit.</div></blockquote>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?</div><div><br></div><div>Sorry but I am still confused. ;-)</div><div><br></div><div>Cheers,</div><div>Bernhard</div></body></html>