<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: 18px; ">Hi Folks,<br><br>(reposted, in the hope of not being ignored)<br><br>Package developers want their work to run on various Squeak versions and variants, without needing rewrite. Same for app developers.<br><br>Base image builders want to be free of the need to provide backwards compatibility.<br><br>This is what I suggest: A package assumes it can use a set of apis of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those assumptions should be made explicit, in the form of tests. So, for example, for collections, some package developer might require the "Common Collection API tests" to pass. Then, if his package fails to run, let's say in Cuis, he would run the tests for the apis he needs. If some test fails, he could say "Cuis developers, you're not supporting api XXX", end expect them to fix the issue. But if no test fails, he needs to either modify his code so it doesn't use not-standarized apis, or he could negotiate with (all) base image developers the addition of a new api or use case to the test suite and the base images.<br></div></blockquote><div style="font-size: 18px; "><br></div><span class="Apple-style-span" style="font-size: 18px; ">Agreed wholeheartedly. </span></div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; "><span class="Apple-style-span" style="font-size: medium; "><div style="font-size: 18px; ">For this vision to have a chance, absolutely one thing is 100% essential. SUnit must be common, between forks, and there must be some way of flagging known exceptions for different target images. This is something I attempted to add to SUnit in August 2006, in eagre anticipation.</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">The second essential thing is for the package loading tools to also be in common. That means Monticello (in my book, though probably not in yours).</div><div><font class="Apple-style-span" size="5"><span class="Apple-style-span" style="font-size: 18px;"><br></span></font></div></span></div><div style="font-size: 18px; ">However, most forks imho are keeping all of their libraries too close to their chests. </div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">All efforts to change this, to move obvious loadable libraries like SUnit, and MC out to be externally managed, have up to now failed. The weakness of my attempts so far has been in the testing side of things. (Matthew Fulmer is worth is weight in gold on that one)</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">However Monticello is a complicated beast, I may have made 400 more commits, merging 3 forks, but one or two bugs is all it takes to reject the entire refactoring of the repositories code, the improved more uniform ui implementation, the password manager, the dual change sorter, the orphanage for out of order loading, public package info properties for package managers, scripting of commits, memory analysis per package, the atomic loader, cleanUp code, improved version numbering, integrated Configurations, separated tests, default packageinfo package types etc etc etc.</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">I always needed others who are more rigourous to join in and help, but so far the vision hasn't caught.</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">I now think it is going to fall to the forks for whom the libraries are already genuinely optional, to pioneer this process. i.e. Cuis.</div><div style="font-size: 18px; "><br><blockquote type="cite"><div>Building these suites is quite some work, mostly to be done by package developers. </div></blockquote><div><br></div><div>As I said, if you try to treat what is perceived as an integral library as an external package, to be maintained by a package developer, with the API maintained by "actual conversation" between the fork-leaders and the package maintainers. The fork controllers wont have any of it, they forked for the purposes of retaining control, and wild horses wont shift them. </div><div><br></div><div>I tried, I asked, I begged, I cried, I explained, and I ranted, in the belief that it was now or never. Up until Pharo, all "forks" were basically differing applications on the same evolving kernel. With Pharo this is different, they are moving the Kernel in a different direction on purpose, however for some reason they believe that forking SUnit, an obviously loadable package, is necessary too!</div><div><br></div><div>Correct me if I am wrong, but in my thinking if SUnit is forked, your vision is pretty doomed.</div><div><br></div><div>SUnit is forked.</div><div><br></div><blockquote type="cite"><div>But it can easily point out responsibilities and duties. It frees package developers of needing to have a deep knowledge of various base images. And it frees base image developers from needing to know details about an unbounded set of external packages. Besides, it puts popular packages that everybody wants to support on equal footing with less-known packages. It also lets base image developers say "we support Common APIs xxx, yyy, zzz, etc.".<br><br>All what I say about base images could also apply to packages that offer services to other packages: There could also be test suites to specify their services, and allow users to switch versions of the packages they use knowing what to expect.<br><br>What do you think?<br></div></blockquote><div><br></div>Like I say, I agree completely, however this is "planning", this is "thinking", this is showing "leadership", and defining a conceptual "process", with conceptual roles and responsibilities.</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">However, may I point out we don't need to do that here, we have a shared repository you can commit your changes to, its called "trunk".</div><div style="font-size: 18px; "><br></div><div style="font-size: 18px; ">Keith<br><div><br></div></div></body></html>