<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Andreas,</div><div><br><blockquote type="cite"><div>And what exactly does that mean? That I'm sitting on all of these great fixes that I won't give to you? Man, you're pathetic.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br><div>The particular one I remember was the scroll list fix, where you piped up "oh I fixed that years ago", and you had the fix in your fork-image but had not fed it back to the community.</div><div><br></div><div><div>Check your emails, I emailed you in 2006 complaining that you were not sharing fixes back to the community. Soon after, for whatever reason, you then started to feed back process fixes for servers, and the situation got better.</div></div><br><blockquote type="cite"><div>My real long-term goal is to enable the Squeak community to be a feasible open source community,</div></blockquote><div><br></div><div>A feasible open source community! And you demonstrate this by ignoring all the community things that were already decided, because you know better, like for example using the "release list" and irc, and the decision not to work in a monolithic image style and so on.</div><div><br></div><div>Technically speaking squeak had no package management tools, no ability to build images without severe pain, no testing server, and every image the release team produces is abandonware. That was in 2006.</div><div><br></div><div>In 2009 we had LPF and mantis actively supporting older images, we had Installer, Sake/Packages for package management, SUnit-improved for running test suites form the command line, and MC1.5 which allowed you to use package overrides, and to work in more complex installation situations. It was all working reasonably well. Bob was up and running in Feb, building "dev" images, and we were ready to begin a monthly release cycle and were looking pretty good.</div><div><br></div><div>We provided tools, with several years worth of work, which the trunk process threw away. You come along 3 months later and say... oh we will need package management, but we haven't thought about it yet. What? That is so obvious we thought of it first and we implemented it. You think a back of the fag packet idea of using a shared repository makes a release process? I don't think so. Especially when your back of a fag packet idea actively stops people (like myself and apparently edgar) from contributing. </div><div><br></div><div>Conceptually your way of working is to use a single monolithic image. Three years ago, we decided that this was no longer the way forward.</div><div><br></div><div>Your monolithic approach is there in stone until you actually have a package management solution. Only when you have a package management solution can a project like Magma load into a kernel image, knowing where to find the missing pieces.</div><div><br></div><div>As a solution for building a production image, squeak has gone back three years, and "trunk" breaks the process that I do have. So a viable feasible oss community, whose leaders institute processes that break your work, without prior consultation, I don't think so.</div><br><blockquote type="cite"><div> to be self-sufficient in its development, to avoid relying on only one or two key contributors, to be able to survive a key contributor to drop out.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>Key contributors are not able to use the trunk process at all. Before you need to survive contributor drop out, you need to appreciate the contributors that you do have and develop a process which can harness their contributions. (In case you didnt know, that was the raison d'etre for bob.)</div><div><br></div><div>Contributors are not dropping out, they are being forced to leave and then people say "... oh but you don't have to use squeak" -- bloody cheek if you ask me. </div><div><br></div><div>Since I was arguably the largest contributor to "squeak the core development tool" over the past three years, I think you would do better to work on your "contributor pissing off rate", that is not a technical problem, that would be a personal, social community problem.</div><div><br></div><div>We saw this happen once before with Pharo (who was it who pissed them off and why?) and we don't want it to happen again. What is conceptually different from your way of working and the pharo way of working... nothing that I can see. Pharo is also a monolithic image under the control of one or two people. If we liked the pharo model we would go there, but we don't. So please dont give us the pharo model. </div><br><blockquote type="cite"><div>That's why I'm trying to channel the energy back into Squeak.org by encouraging projects like Croquet and Etoys to move back on top of Squeak.org; that's why I'm seeing Cuis at one end of the spectrum that we need to support (cf. the recent discussions about Cuis and Squeak being supersets one way or the other) and if it weren't for personal animosity I'd be trying to convince Pharo to join the effort as well. That's also why I'm trying to broaden the base of core developers and that's why I feel that collaborating on a shared artifact (the trunk) is the right direction forward.<br></div></blockquote><div><br></div><div>Well it isn't, because trunk is a barrier to contribution, because it it pitched at too high a level, that is why bob used ChangeSets.</div><div><br></div><div>Secondly the image need to be split up into parts that can be integrated, the idea of having one monolithic artefact is a hugely backward step.</div><div><br></div><div>I offered you a compromise, that compromise was to not use one monolithic repository, but to package separate innovations separately, i.e Compiler is a separate integratable piece. Produce a compiler version 1.0.0 and enable others to load and integrate it. I will produce a changes/sources 1.0 soon enough. etc etc.</div><br><blockquote type="cite"><div>All of the projects have a role in the grand scheme. They're all Squeak and if we split our efforts five-ways nobody is going to win.</div></blockquote><div><br></div><div>You are the one splitting the efforts. You force the issue by making everyone sing the one tune, "trunk", and leaving the rest of us by the way side. If I can pick up the stragglers I will, but sooner or later you will have more stragglers than you do have contributors.</div><div><br></div><div>Note I haven't seen a single contribution to trunk that I actually need for my work, its all nice to have stuff. Yet you threw away a bunch of essential bits and pieces to get there. Package management is not an optional extra to add when you feel like it, it is a pre-requisite to any coherent solution of integrated parts. </div><div><br></div><blockquote type="cite"><div> We need a strong development base -Squeak- and from there we have the various directions and environments, Etoys, Croquet, Cuis, Seaside, Pharo, you name it.<br></div></blockquote><div><br></div><div>The strong development base comes form the community that can work together. Squeak was undermined by you, not appreciating the contributions and the effort and the investment that had already been done.</div><div><br></div><div>Your back of a fag packet idea, only develops one artefact, that is divisive, it forces people to make the choice.</div><div><br></div><div>My back of a fag packet idea, that I am using in cuis, develops all artefacts, including pharo. (so did bob)</div><div><br></div><blockquote type="cite"><div><br><blockquote type="cite">My agenda was the opposite - to provide tools that you could make the<br></blockquote><blockquote type="cite">image anything you wanted it to be. One is about control, the other is<br></blockquote><blockquote type="cite">about liberty.<br></blockquote><br>No, the former is about collaboration on a shared artifact. If you think I'm "controlling" the trunk please provide an example for how exactly I'm doing that in your opinion.<br></div></blockquote><div><br></div><div>1) One email to squeak-dev saying "here is the new development process", when actually we had a development process already.</div><div><br></div><div>2) "trunk" is not a place I can publish my new sources/changes stuff until it meets your requirements, (trust me it will break) What if I want to provide 3 different solutions to the sources/changes issues. Trunk can only cope with one at a time. You see? It is divisive it is not offering people choices, it is offering them your choice on their behalf.</div><div><br></div><div>regards</div><div><br></div><div>Keith</div><div><br></div></div> </body></html>