Hi Andreas,

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

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.

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.

> My real long-term goal is to enable the Squeak community to be a  
> feasible open source community,

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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

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.

Your back of a fag packet idea, only develops one artefact, that is  
divisive, it forces people to make the choice.

My back of a fag packet idea, that I am using in cuis, develops all  
artefacts, including pharo. (so did bob)

>
>> My agenda was the opposite - to provide tools that you could make the
>> image anything you wanted it to be. One is about control, the other  
>> is
>> about liberty.
>
> 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.

1) One email to squeak-dev saying "here is the new development  
process", when actually we had a development process already.

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.

regards

Keith

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100312/4b40e0cb/attachment.htm