> No.  Trunk is an enabler, not an institution.

Trunk is a fork. It is one product serving one agenda.

We had already moved beyond this in detailed discussions with the  
board, recognising that squeak is no longer one product, we wanted a  
process that supports multiple products, and multiple forks, because  
that is the reality we are in, and so we specified the components to  
develop and the approach that would be required as a basis to enable  
this to happen.

Cross fertilisation cannot happen effectively if everyone is working  
to a moving target all of the time, and fixed points only occur once  
every 1-2 years.

What is needed conceptually is the following, fixed points every 2  
months at the minimum, and each innovation packaged for that fixed  
point, or provided as a delta, relative to those fixed points. The  
number of big compatibility breaking innovations published per fixed  
point should be limited to 1 or two per month, in order not to  
overwhelm people with too much.

Then if you are a non-mainsteam fork (like cobalt) you can look at the  
innovation and work out how to port it to your local fork, because you  
can see the stable state of the other dependencies in the fixed point.

Please think about this. Then you will understand why trunk is a bad  
thing, it is the antithesis of what we actually decided we needed.

>  The squeak board doesn't count as much of an institution because it  
> lacks funds.  Trunk excludes no one, everyone has read rights.

The board is an institution if it acts like one. It is a dictatorship  
if it acts like one.

Trunk excludes me, I have made this clear several times.

Trunk only has one head, so it excludes anyone who wants to go in a  
different direction, or those who are already supporting images that  
are not trunk compatible, like me.

> t is clearly not an obstacle to progress;

Trunk is an obstacle to progress, because I cant make my contributions  
to it.

Trunk is an obstacle to progress because we have to wait a year for a  
release, again!

Trunk is an obstacle to cross fertilisation of patches or innovations  
because it is a moving target.

> Once we have smaller kernels

Trunk is not a fast route to smaller kernels, since no actual thought  
was put in to how you would get from A to B. Getting from A-B and back  
again if you want to, requires thought and tools to do so. This is why  
we developed the tools first, rather than throw a new image at the  
community with no tools.

> we will be able to evolve the underlying execution machinery more  
> easily and implement different object representations and more  
> efficient garbage collectors, but the broader community won't be  
> inconvenienced because their packages will still load.  Assuredly  
> however old images will be left behind, and the best way of bringing  
> old code forward will be to publish it as a package and load it into  
> a new image.

The best way of bringing old code forward, is to back-port the new api  
into the old image, so that you only need to maintain one codebase for  
both. When all of your packages are individually working in both the  
old image and the new, then you can migrate to the new image, and  
there is never a point at which anything stopped working.

For example, the change which merged ifNotNil: and ifNotNilDo: [:n | ]

If you do it your way, and have to port 60 packages, even ones you  
don't own, then you end up with months of what is effectively  
downtime, or months where you have to maintain two codebases.

> What we really need as an essential starting point is actually the  
> kernel image that we have talked about for so long. So thank you  
> Juan Vuletich, thank you for your kernel image, I am sure it will go  
> far.
>
> And who is making the fastest progress towards that goal right now?   
> You or Andreas and Juan?

Looks like it is Juan.

>  Are you helping them or hindering them?

Why cant it be, are they helping me or hindering me? Andreas is the  
new kid on the block when it comes to working towards a smaller image  
and multiple forks. I have been working on it for 3 years, tools first.

The board should not play favourites. I put 4 years of effort into  
squeak too you know. However I had to write a proposal, and get it  
voted upon. Andreas didn't because he used his position on the board  
to impose his non-plan. We already had a shared repository, it was  
called somewhat logically squeaksource.com/311

Andreas started by going backwards, he started with not understanding  
(which he later admitted), then not-communicating, he started by using  
squeak-dev when I specifically asked him not to. He started by  
instituting a process I could not contribute to, and he started by not  
building upon anything that we had worked on already.

This is just as rude as the pharo guys starting on 3.9 and insulting  
Edgar's long-suffering efforts.

> We're free to make that choice.  But even better were free to not  
> make a false or forced choice.  In the package world there is no  
> insurmountable separation between Cuis and Trunk or Pharo or Etoys.

Yes there is if the packages are all being developed relative to a  
moving target.

Your rose-tinted view is to be expected as a low level guy. Those who  
simply write packages on top of their one chosen image, dont really  
get effected by this very much. This is why the pharo guys who are  
academics producing a package for the purpose of writing a paper or  
two dint understand this either and those who write all their code  
themselves dont understand what I am going on about.

However if you are building large systems which integrate on top of  
packages on top of packages, and between packages, then the number of  
moving targets ups the variables considerably, and at some point  
progress becomes impossible. Think fragile base class problem x 100.

>  Code is moving in packages between all of them (and in changesets  
> when it can't be accomplished easily with packages).  Open your eyes  
> and ears man, and stop shouting at deaf ears.

Yep shouting at deaf ears is about right, you aint listening, and you  
aint understanding.
>
> P.S.  In offence of Godwin's law I can't help but see the metaphor  
> between Keith's model of continuous integration of everything into  
> everything else and of Clay Shirkey's institutions vs communities  
> and of Stalinism and the fall of Communism.  There are great virtues  
> in socialism (change sets) but when institutionalised (bob) it  
> becomes monstrous (inefficiency of maintaining pointless backwards  
> compatibility).  ;) ;) ;)

You got this a bit wrong, again you lot didnt bother understanding  
before pronouncing. Bob is the non-institutional tool, because it is a  
standalone service, that can get an image from anywhere, perform a  
task on that image and test it, without requiring the image to have  
any dependencies.

Trunk, requires you to have an image with a specific version of  
Monticello, and PackageInfo, MonticelloConfigurations, HTTPSocket,  
HTTPClient, Network, Compession etc etc etc.

My reference to facism, is primarily based upon the boards lack of  
willingness to define a constitution or boundaries for itself. This  
approach has been seen before. Secondly it appears that many members  
of the community here present do not have the moral fibre to see that  
if someone is mistreated, actual steps need to be taken to make sure  
it doesnt happen again. It is not ok. You are 51 years old, you have  
kids, you know this really.

cheers

Keith




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100123/5f1021f1/attachment.htm