<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><font class="Apple-style-span" color="#000000"><br></font> The trunk process is a "grand project" which hasn't produced anything of any use for 6 months. It signs up the community for an ongoing wait of 12-18 months per release. It ties you in to the "grand project" ethos which we all said we didn't want.<br> </blockquote><div><br></div><div>Nonsense. In the past 6 months, just to take three that come to mind, we have closures, native fonts and unloadable smaller traits. There are lots of other things also; go look at the recent changes list. Trunk is actually progressing very nicely.</div></div></blockquote><br></div><div>Hi Elliot,</div><div><br></div><div>First of all these things are of no use to me, because my code base will take about 2 months to port, longer since I now have to port the tools as well.</div><div><br></div><div>You might think you are doing the community a service, but actually you haven't provided stuff or "captured knowledge" that the existing community can use easily. All you have done is encouraged some members of the community to abandon the rest of us, moving over to developing stuff for a new image that I cant use, leaving behind compatibility. My production images don't have closures, the customer asks for an update, I cant load the latest seaside if it uses closures for example. This is the same as the pharo "stuff compatibility" attitude and they are also developing stuff I cant use.</div><div><br></div><div>For example, Magma runs in Pharo and 3.7 - 3.10, apparently you provide closures, but if closures aren't available as a loadable/applyable feature for 3.7 then magma has to choose either not bother to use closures, maintain two or three codebases, or drop support for older images. The knowledge to implement closures has been redone 3 times now, in trunk, pharo, and cuis, but I don't have the expertise to do it myself.</div><div><br></div><div>I think you misunderstand me my gripe is not about making progress, it is about throwing all the knowledge into one disorganised pot, aka "trunk".</div><div><br></div><div>If you had kept the knowledge needed to implement closures as a separate initiative, in a separate repo, with separate change sets, scripts etc then other people could harvest that knowledge, either all or in part, and you would be contributing "knowledge" that I could import into my codebase. Perhaps cobalt would like closures too. Cobalt is not going to be able to move to build on trunk-alpha overnight either, so they are going to have to do it all over again.</div><div><br></div><div>The same goes for bug fixes. Previously we had 100 fixes ready to load into 3.10 from mantis, all documented, and supplied in their natural form "changesets". Throwing fixes into trunk, dilutes the knowledge, and makes it only useful for trunk users and no one else. I cant harvest a fix out of trunk, into my image.</div><div><br></div><div>I suggested a compromise back in August, that Andreas ignored completely. That if trunk development was split into clearly defined initiatives with separate projects, then we would be able to work together.</div><div><br></div><div>Again feel free to correct me if I am wrong.</div><div><br></div><div>Keith</div><div><br></div><div> </div></body></html>