Hi Keith,

On Fri, Jul 10, 2009 at 3:16 PM, Keith Hodges <keith_hodges at yahoo.co.uk>wrote:

> Andreas Raab wrote:
> > Hi Keith -
> >
> > Let's cut this discussion short a little since I don't think either
> > one of us is going to convince the other. To summarize, my position is
> > that yes, you've done some interesting work with SUnit, but the
> > reality is that this doesn't entitle you to anything. If you want your
> > code to be used you've got to create trust into what you've done
> > (i.e., have users) and you've got to convince others to include it
> > (i.e., work with the distros). This goes for anything we do in open
> > source but doubly so if core packages are involved.
> >
> > Cheers,
> >   - Andreas
> The distro's are effectively a closed shop.
>
> That is the whole point of replacing the release process with something
> that is distributed and allows many different images to be built.
>
> Keith



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.

Consumers can fall into some broad categories
- experienced squeakers who want to have at the system in all its glory and
program as the system was intended to permit programming
- new aspiring experienced squeakers who want to use the system in the same
way
- educators who wish to use the system to teach
- students who wish to be taught programming in the context of squeak
- people who want to run some application developed in squeak without
delving into the system other than superficially
- commercial entities through to hobbyists who want to deploy applications
they're written in squeak for profit or not

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.

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.

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.

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.

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.

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.

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.

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.

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).

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).

Anyway, my 2¢.

Summary, can we not merge, or if not, marry, your auto-integration testing
framework with a package-based approach?

the weekend beckons..

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090710/652c5f5c/attachment.htm