<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="font-size: 14px; ">Keith, if you still didn't understood my message, let me elaborate.<br>1. All your ideas/arguments about techical issues is highly rational.<br>2. But instead of using power of arguments, and looking for<br>compomise</div></blockquote><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">1)</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">I proposed a workable compromise immediately after Andreas' original email, it was ignored!!!!</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">2)</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">There is no compromise, you aren't providing me with a workable solution. I can't use trunk, the trunk process is not managing anything of interest or use to me or my client because I was providing tools. </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">a) tools that trunk cant load and </div><div style="font-size: 14px; ">b) and tools that are managed outside of trunk, </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Since anything outside of trunk is ignored as a possible solution, because you still have your monolithic blinkers on, and the board is still driven by the idea that "oh my goodness Pharo has a new image and we dont". </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">You are forgetting that in Bob you have a viable "extreme programming style continuous integration development platform", when in Pharo they don't, but Bob is ONLY viable IF YOU USE IT.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">When you have a project manager whose goal is to produce an image with fancy fonts (lol), rather than a "comprehensive extreme programming capable development platform", you are going to produce conflicting strategies.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">You are all so wrapped up in hacking trunk, you aren't the slightest bit interested in moving forward on the tools. Sure Andreas wants a package manager, on his terms only though. I cant port my production images to trunk easily, and when 3.11 is released, I could spend 2/3 months porting my stuff, but since you lot wouldn't even do me the courtesy of starting with 3.10-build, you make it harder for me. You are also probably going to pick a different package management system so all my current package definitions will have to be redone from scratch, any work I do or have done on tools has been discarded by you lot.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">I rejoined squeak-dev and started the fight again, because I suddenly realised that you had actually left me in a position where I had no way forward at all, I had thought I could move to pharo, until I actually tried their image, ugh, what a disaster (OmniBrowser) and guess what, all my package definitions will have to be redone from scratch.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Anyhow in six months time the client is going to say, "what shall we do next" and I will end up saying, why don't you get someone else to do it in python or whatever you like, because squeak is not a viable platform any more, nor is pharo. </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">The viability of the platform is entirely bound up in the politics, and the ability of the community to collaborate and share stuff more than the technical side of things. Witnessing one individual overrule that the way forward is a hacking away unplanned process, to produce an incompatible image, without any tools being provided for us to use in our work, is damaging for the viability of squeak as a professional development platform. Then it appears that there isn't the will in the community to develop, provide, support and USE the tools we need to do a professional tested job. </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">The current focus of the community as endorsed by the board is on hacking at trunk which is an irrelevant task as far as we are concerned since our starting image is basically arbitrary because we use an automated build, 3.8 works fine for us. Cuis is an attractive target as anything because it is small and fast. (but it has no tools yet!)</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">However now that the "release-team" is hacking at trunk, rather than providing a working process and tools which we could adopt in-house to do a good professional job for our clients. Squeak ceases to be an interesting platform because it hasn't got any continuous integration tools, it has no vision for such tools, and those it has got have just been discarded by the community without a second thought.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Now if I continue to develop these tools for my use only, while you are all hell bent on building trunk and doing everything is exactly the opposite way that is of any actual use, using either no tools or other tools that are not compatible with my tools. I will not and cannot compete, you win, and my client will end up back with python where they started.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Juan has it right, his vision is to produce "the best kernel he can", but not on any account to interfere with the users of the kernel and what they might want to do with it. This frees me up to implement "a grand vision", without having it trashed at a moments notice, by someone else coming along with a lesser vision.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">My client chose squeak because of the potential and the open collaborative dynamics of the community that they saw on irc that were interested in tools, and extreme programming approaches, particularly release often, and test always. If I use BOB to build and regression test my code it only makes sense if the seaside team also uses Bob to build and regression test their code and the same goes for magma etc etc.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Those dynamics and collaborative dynamics have now gone, as has the interest in tools and its a case of what Andreas says goes, and what Andreas says is we are going to produce a 3.11 image come hell or high water without tools, without regression testing and without a rapid release cycle integrating carefully planned and proven projects which are separately published. Neither the squeak board or the trunk developers are doing anything to make squeak a first class development platform that is developed daily using continuous integration and extreme programming tools and techniques.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">There is this new 3.11 image promised down the line, but its not developed with our needs in mind, it isn't developed with the tools we want to use, it isn't tested against the packages we want to use yet, and uncle Tom Cobbly (anyone) can change an API at the drop of a hat. Oh and it will be a year until the subsequent release.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">3)</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">The board is not providing a compromise basis either, since it refuses to provide "terms of reference".</div><br style="font-size: 14px; "><blockquote type="cite" style="font-size: 14px; "><div>s, you choosen to fight with everyone,<br></div></blockquote><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">I am only virtually fighting against the impossible situation you have put me in, and the complete lack of thinking going on here. To be clear once more, I can build an production image on any base image, so the trunk image itself is irrelevant. What is relevant is the process by which the 3.11 image is developed on an ongoing basis, and the bug fixes that are published against individual releases. If I choose 3.11 as the basis for a project I want to know that bug fixes will be provided for THAT image, not for trunk2, the client wants to know that bug fixes are available for an image that has a bug found in it, not an image that we have to wait 18 months for.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">I am also fighting against those who don't bother communicating. For example Craig where are you, you are as responsible for this mess as anyone else. Andreas nor the board didn't email me for 2 months to ask for a progress update. You will see I mellow somewhat as people who enter into a conversation with me, I mellow. Elliot talks sense, and Josh too.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">But no matter how much sense they make, no compromise is being offered, because you still see the future of squeak as an image release, and I see it as a development platform and series of processes that need tools (which don't care about the image). While the board puts the power into Andreas' hands to dictate the future of squeak, there is no future of squeak the development platform, there is only a 3.11 image, big deal.</div><br style="font-size: 14px; "><blockquote type="cite" style="font-size: 14px; "><div>defending your position, up to the point, that it is not really<br>matters, who is right or wrong , and in what they right or wrong.<br>You just subbornly keep fueling a conflict, which nobody, except you<br>want to have.</div></blockquote><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">While you continue to use the argument "the end justifies the means" you are picking the fight. Just because no one stands up to you, doesn't mean it is an acceptable attitude to have. The fact that "the end" in this case is to divert valuable resources into an minimally relevant hole called "trunk".</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Plot the number of users of images derived from 3.7, 3.8, 3.9, and 3.10 see how it falls. 3.8 still has the most users, 3.11 will have about 20 users max by the time you have finished.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Like I said "Terms of Reference" are important, but a new image developed without tools is not. </div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">The deliverable of squeak, is a published image, AND a toolset for building and deriving distribution images, AND up to date package definitions for all packages, AND a Bug Tracker that is used to publish Bug fixes against said published image.</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">You are right I don't expect any compromise to be possible. Andreas has it nailed up so there isn't any possible. But at least this way people might actually think...</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">cheers</div><div style="font-size: 14px; "><br></div><div style="font-size: 14px; ">Keith</div><div style="font-size: 14px; "><br></div></div><br style="font-size: 14px; "></body></html>