Hi Keith,<br><br><div class="gmail_quote">On Fri, Jul 10, 2009 at 3:16 PM, Keith Hodges <span dir="ltr"><<a href="mailto:keith_hodges@yahoo.co.uk">keith_hodges@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Andreas Raab wrote:<br>
> Hi Keith -<br>
><br>
> Let's cut this discussion short a little since I don't think either<br>
> one of us is going to convince the other. To summarize, my position is<br>
> that yes, you've done some interesting work with SUnit, but the<br>
> reality is that this doesn't entitle you to anything. If you want your<br>
> code to be used you've got to create trust into what you've done<br>
> (i.e., have users) and you've got to convince others to include it<br>
> (i.e., work with the distros). This goes for anything we do in open<br>
> source but doubly so if core packages are involved.<br>
><br>
> Cheers,<br>
> - Andreas<br>
</div>The distro's are effectively a closed shop.<br>
<br>
That is the whole point of replacing the release process with something<br>
that is distributed and allows many different images to be built.<br>
<font color="#888888"><br>
Keith</font></blockquote><div><br></div><div><br></div><div>For me this raises the need to step back from the conversation about the development process and talk about the artifacts the community produces and who the consumers of those artifacts are.</div>
<div><br></div><div>Consumers can fall into some broad categories</div><div>- experienced squeakers who want to have at the system in all its glory and program as the system was intended to permit programming</div><div>- new aspiring experienced squeakers who want to use the system in the same way</div>
<div>- educators who wish to use the system to teach</div><div>- students who wish to be taught programming in the context of squeak</div><div>- people who want to run some application developed in squeak without delving into the system other than superficially</div>
<div>- commercial entities through to hobbyists who want to deploy applications they're written in squeak for profit or not</div><div><br></div><div>There are probably other meaningful categories, and some people occupy more tan one category concurrently. But you get my drift. Not everyone wants to wrestle with the full glory, but those that do are likely to contribute to the system's subsequent evolution, fix bugs, etc.</div>
<div><br></div><div>It makes sense to me that all but the first want to start with a known quantity, something that is identified, has people who will try and help with problems with it, something around which a community is focussed, something with a hoped-for future, something documented and perhaps even written about. In short a distro. If that distro isn't in some sense a "closed shop", if its anything like a fast-moving target then it'll satisfy only the experienced few, the gurus, who can roll up their sleeves and have at it.</div>
<div><br></div><div>So I see a contradiction in, Keith, your promotion of an open development model and at the same time an assumption of greater community participation. I suspect that for most new community participants the existence of a few well-differentiated and well-supported distros is a necessity.</div>
<div><br></div><div>So what would make sense to me is a development model which tries to gather maintennance contributions from those that are capable of and happy to fix problems with the system and harvest them to make stable distros, a clearing house that verifies or rejects potential bug fixes, filters potential candidates for inclusion, so that the maintainers of distros have an easier job in moving their slower-moving targets forward.</div>
<div><br></div><div>I want to say more about the kinds of artifacts the community might produce but the weekend is advancing and I'm about to dive into the bosom of my family for the weekend and leave the internet behind. So this is too brief. But I think people want to provide functionality in different forms.</div>
<div><br></div><div>One important form is the cross-dialect package, such as Seaside, which is a core package plus compatibility code to adapt it to various Smalltalks, not just various Squeak dialects.</div><div><br></div>
<div>One form, of necessity, is the package imprisoned in an image, such as eToys and QwaqForums where on the one hand the lack of modularity means that its too difficult to extract a package and on the other hand where the necessities of making radical changes to move the artifact forward result in a fork.</div>
<div><br></div><div>Other forms are kitchen-sink images appealing to power developers, various forms of cut-down images attempting to get to a kernel as a suitable starting point for modular composition, and so on.</div><div>
<br></div><div>All of these would benefit from a more modular system, especially one that had a small bootstrappable kernel that would allow the execution technology to move forward without breaking them, and without having to repeat bootstraps in place (yes I have a perspective here, porting closures to numerous images is not my idea of fun).</div>
<div><br></div><div>So again I see issues with your development model. I think it is well-suited to the maintennance task, and important in getting to the small kernel that we want. But it needs to dove-tail with a package-based model because that's the model that gives most power to the community going forward in that it results in packages that can be deployed in different contexts and maintained to some extent independently of a specific substrate, and is the one that allows the community to evolve at its maximum rate. (It is still extraordinary the Squeak has had the same slow VM technology for 14 years).</div>
<div><br></div><div>Anyway, my 2¢.</div><div><br></div><div>Summary, can we not merge, or if not, marry, your auto-integration testing framework with a package-based approach?</div><div><br></div><div>the weekend beckons..</div>
<div><br></div><div>best</div><div>Eliot</div></div>