[squeak-dev] Re: [Election] ...is soon upon us! Last day info
keith_hodges at yahoo.co.uk
Fri Mar 12 17:12:26 UTC 2010
> 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
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
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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev