<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"> </div></blockquote><div>No. Trunk is an enabler, not an institution. </div></div></blockquote><div><br></div><div>Trunk is a fork. It is one product serving one agenda.</div><div><br></div><div>We had already moved beyond this in detailed discussions with the board, recognising that squeak is no longer one product, we wanted a process that supports multiple products, and multiple forks, because that is the reality we are in, and so we specified the components to develop and the approach that would be required as a basis to enable this to happen.</div><div><br></div><div>Cross fertilisation cannot happen effectively if everyone is working to a moving target all of the time, and fixed points only occur once every 1-2 years.</div><div><br></div><div>What is needed conceptually is the following, fixed points every 2 months at the minimum, and each innovation packaged for that fixed point, or provided as a delta, relative to those fixed points. The number of big compatibility breaking innovations published per fixed point should be limited to 1 or two per month, in order not to overwhelm people with too much.</div><div><br></div><div>Then if you are a non-mainsteam fork (like cobalt) you can look at the innovation and work out how to port it to your local fork, because you can see the stable state of the other dependencies in the fixed point.</div><div><br></div><div>Please think about this. Then you will understand why trunk is a bad thing, it is the antithesis of what we actually decided we needed.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div> The squeak board doesn't count as much of an institution because it lacks funds. Trunk excludes no one, everyone has read rights. </div></div></blockquote><div><br></div><div>The board is an institution if it acts like one. It is a dictatorship if it acts like one.</div><div><br></div><div>Trunk excludes me, I have made this clear several times.</div><div><br></div><div>Trunk only has one head, so it excludes anyone who wants to go in a different direction, or those who are already supporting images that are not trunk compatible, like me.</div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>t is clearly not an obstacle to progress; </div></div></blockquote><div><br></div><div>Trunk is an obstacle to progress, because I cant make my contributions to it.</div><div><br></div><div>Trunk is an obstacle to progress because we have to wait a year for a release, again!</div><div><br></div>Trunk is an obstacle to cross fertilisation of patches or innovations because it is a moving target.</div><div><br><blockquote type="cite"><div class="gmail_quote"><div>Once we have smaller kernels</div></div></blockquote><div><br></div><div>Trunk is not a fast route to smaller kernels, since no actual thought was put in to how you would get from A to B. Getting from A-B and back again if you want to, requires thought and tools to do so. This is why we developed the tools first, rather than throw a new image at the community with no tools.</div><br><blockquote type="cite"><div class="gmail_quote"><div> we will be able to evolve the underlying execution machinery more easily and implement different object representations and more efficient garbage collectors, but the broader community won't be inconvenienced because their packages will still load. Assuredly however old images will be left behind, and the best way of bringing old code forward will be to publish it as a package and load it into a new image.</div></div></blockquote><div><br></div><div>The best way of bringing old code forward, is to back-port the new api into the old image, so that you only need to maintain one codebase for both. When all of your packages are individually working in both the old image and the new, then you can migrate to the new image, and there is never a point at which anything stopped working.</div><div><br></div><div>For example, the change which merged ifNotNil: and ifNotNilDo: [:n | ]</div><div><br></div><div>If you do it your way, and have to port 60 packages, even ones you don't own, then you end up with months of what is effectively downtime, or months where you have to maintain two codebases.</div><div><br></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; "><div style="word-wrap:break-word"><div style="font-size:15px">What we really need as an essential starting point is actually the kernel image that we have talked about for so long. So thank you Juan Vuletich, thank you for your kernel image, I am sure it will go far.</div> </div></blockquote><div><br></div><div>And who is making the fastest progress towards that goal right now? You or Andreas and Juan? </div></div></blockquote><div><br></div><div><div>Looks like it is Juan.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div> Are you helping them or hindering them?</div></div></blockquote><div><br></div><div>Why cant it be, are they helping me or hindering me? Andreas is the new kid on the block when it comes to working towards a smaller image and multiple forks. I have been working on it for 3 years, tools first.</div><div><br></div><div>The board should not play favourites. I put 4 years of effort into squeak too you know. However I had to write a proposal, and get it voted upon. Andreas didn't because he used his position on the board to impose his non-plan. We already had a shared repository, it was called somewhat logically squeaksource.com/311</div><div><br></div></div><div>Andreas started by going backwards, he started with not understanding (which he later admitted), then not-communicating, he started by using squeak-dev when I specifically asked him not to. He started by instituting a process I could not contribute to, and he started by not building upon anything that we had worked on already.</div><div><br></div><div>This is just as rude as the pharo guys starting on 3.9 and insulting Edgar's long-suffering efforts. </div></div><br><blockquote type="cite"><div class="gmail_quote"><div>We're free to make that choice. But even better were free to not make a false or forced choice. In the package world there is no insurmountable separation between Cuis and Trunk or Pharo or Etoys.</div></div></blockquote><div><br></div><div>Yes there is if the packages are all being developed relative to a moving target. </div><div><br></div><div>Your rose-tinted view is to be expected as a low level guy. Those who simply write packages on top of their one chosen image, dont really get effected by this very much. This is why the pharo guys who are academics producing a package for the purpose of writing a paper or two dint understand this either and those who write all their code themselves dont understand what I am going on about.</div><div><br></div><div>However if you are building large systems which integrate on top of packages on top of packages, and between packages, then the number of moving targets ups the variables considerably, and at some point progress becomes impossible. Think fragile base class problem x 100.</div><br><blockquote type="cite"><div class="gmail_quote"><div> Code is moving in packages between all of them (and in changesets when it can't be accomplished easily with packages). Open your eyes and ears man, and stop shouting at deaf ears.</div></div></blockquote><div><br></div><div>Yep shouting at deaf ears is about right, you aint listening, and you aint understanding.</div><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>P.S. In offence of Godwin's law I can't help but see the metaphor between Keith's model of continuous integration of everything into everything else and of Clay Shirkey's institutions vs communities and of Stalinism and the fall of Communism. There are great virtues in socialism (change sets) but when institutionalised (bob) it becomes monstrous (inefficiency of maintaining pointless backwards compatibility). ;) ;) ;)</div></div></blockquote><br></div><div>You got this a bit wrong, again you lot didnt bother understanding before pronouncing. Bob is the non-institutional tool, because it is a standalone service, that can get an image from anywhere, perform a task on that image and test it, without requiring the image to have any dependencies.</div><div><br></div><div>Trunk, requires you to have an image with a specific version of Monticello, and PackageInfo, MonticelloConfigurations, HTTPSocket, HTTPClient, Network, Compession etc etc etc.</div><div><br></div><div>My reference to facism, is primarily based upon the boards lack of willingness to define a constitution or boundaries for itself. This approach has been seen before. Secondly it appears that many members of the community here present do not have the moral fibre to see that if someone is mistreated, actual steps need to be taken to make sure it doesnt happen again. It is not ok. You are 51 years old, you have kids, you know this really.</div><div><br></div><div>cheers</div><div><br></div><div>Keith</div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>