<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Keith,<br>This is absurd. We can not develop trunk patches in 3.10.2.<br>If it would be true, that would mean that you can take all the<br>"patches" applied from 3.10.2 up to latest trunk and reload them in<br>any order.<br></div></blockquote><div><br></div>Correct. </div><div><br></div><div>however not quite in any order though, dependencies can be defined if needed. Check the "theory of patches" used by "darcs" SCM. This is fairly close to the hypothesis behind darcs.</div><div><br></div><div>However you cant do this with trunk because, you have a years worth of work in trunk. If you do not release more often, your deltas become too large to manage on this basis.</div><div><br></div><div>The original goals for developing the release process included monthly time boxed releases. (slowed down to bi-monthly to allow everyone to keep up)</div><div><br></div><div>When "trunk" is proposed, why didn't anyone ask the question, how long till the next release, over a year... forget it.</div><div><br></div><div>Point of fact, the time is soon approaching when we will have waited longer for a release from the trunk process, than I was allowed on 3.11.</div><div><br><blockquote type="cite"><div>I really want you to try before speaking.<br>I wonder what other squeakers think about closures/faster sets/new<br>trailers/SmalltalkImage etc... :<br>- shall we revert them and wait for a better engineered universal<br>loading procedure ?<br></div></blockquote><div><br></div><div>Well firstly you could have actually tried using the loading procedure that I put so much time into developing rather than ignoring it.</div><div><br></div><div>Secondly at the point when Andreas override my work, I was documenting bob on vimeo, bob was released in February 2009, so you could have used it then. So what were you thinking you had to wait for?</div><div> </div><div>Secondly release teams have been saying that they wanted atomic loading for, I don't know 5 years now?!? Where is it if it is such a priority for making things easier?</div><div><br></div><blockquote type="cite"><div>- or are we happy with a better than nothing trunk-only version ?<br></div></blockquote><div><br></div><div>If you are happy to settle for a better than nothing solution, you could have had the courtesy to actually ask what the state of play was on bob stuff before replacing it, with a worse than nothing solution.</div><div><br></div><blockquote type="cite"><div>In fact, these are not even trunk-only, because Juan, you and pharoers<br>can take a part of the burden and port important things to fork.<br></div></blockquote><div><br></div><div>This is where the problem lies. We would love to, however you have explicitly chosen a process which makes this hard, and you have put the knowledge in a form which is very difficult to harvest.</div><div><br></div><div>It will usually take as much effort to port it as to implement it in the first place. So trunk is no help there.</div><div><br></div><blockquote type="cite"><div>I don't say that the statu quo is ideal, nor that we should not<br>improve inter-fork exchange, but Keith, not this model please !<br></div></blockquote><div><br></div>Well I would say the same thing. Not this model please, anthing but this.</div><div><br></div><div>Dont develop fixes on top of fixes on top of fixes, and then expect someone else to sift through and work out what the hell is going on.</div><div><br></div><div>Develop ONE fix, and refine it over time, when it is ready publish it, and a single discrete lump, against a known fixed point, that you can see the delta clearly.</div><div><br></div><div><div>Keith</div><div><br></div></div><div><br></div><div><br></div><div><br></div><br></body></html>