> Hi Keith,
> Yes I know your point as I readed everything you wrote about it,
> but I must say that I appreciate the interactivity that Trunk give us
> with Squeak.
> I think we lost that when we put aside BFAV and the capacity to update
> Squeak image from
> within the image. The possibility you offers to the community with LPF
> and Bob
> seems to me really interesting 
Glad you liked it...  it wasn't supposed to be "interesting" this was
the endorsed way forward as selected by the board via written proposals
and a lot of now wasted effort.
> and an improvement except that we lost daily interactivity
Daily interactivity was part of the previous plan. You can automatically
load whatever fixes you want from mantis and check that they work. There
is also an automated process to load them all if you want to. All the
code for generating the next image is available for you to contribute
to, and test, it used to be publically visible on a wiki, it is now
managed in monticello. Its all there.

This included support for multiple innovative paths, and multiple
derived images. Now you only have Andreas' controlled path, from which
most mortal contributors will eventually be banned because you aren't
supposed to break things. This effectively shuts me out of the
development process because I continuously break things. We are back to
a process in which there is no place for me to contribute and that is
the core of my objection to it.

We are also back to a process in which all contributions are being made
to the image, and so progress is erroneously being measured by only
looking at the image and ignoring tools and support services. People
whined about no progress in squeak relative to Pharo, but in truth we
were way ahead of pharo in many aspects, simply because we took the
goals of both squeak and pharo (in truth pharo's goals were the same as
ours in the first place except for backwards compatibility for which we
have a process and pharo doesn't) and we actually spent time planning
and implementing the tools to put those goals into effect. For example
"atomic loading" was noted as an essential must have item by several
previous development teams, so we worked on that instead of blindly
wading through the existing mud.

Pharo don't have automated testing, out of order loading, MC that works,
atomic loading. They are no where near a release early and often process
with automatically tested derived images. (and now neither are we).

Also now that fixes are moved into the trunk manually, you are loosing
the whole point of automating the interface to mantis.

You also lost the ability to engineer a new solution and simultaneously
plan its integration into Squeak and all loadable squeak packages.
Currently you have to hit a moving target of whatever random thing
Andreas is working on at the time. None of the loadable squeak packages
will be keeping up with trunk, so you will not get to integrate your
solution with them either because they will most likely be broken.
> with squeak fixes (don't know if 'interactivity'
> is a good word but hope you get the idea).
>
> For now, I still think there is place for both of these mecanisms, 
Technically may be, but there is no vision, there is no management, no
planning. Andreas threw all of that away. Unfortunately Andreas decided
to run on ahead and replace the previous plan competing with it rather
than contributing to it. I haven't seen any replacement plan, except for
Andreas popping up and telling us what he has already been working on
after the event.  In my book that's called hacking, and it doesn't lend
itself to any form of management or planning, apart from what goes on
inside Andreas' head.
> but we still
> have to find how and when and where in our process.
What you are calling "our" process is the antithesis of the plan we
looked at carefully and decided that we needed, with the board's approval.

The process I proposed, was formed out of 3 years of work in which I
made contributions to the current state of squeak continuously for 3
years. Andreas made no contributions (apart from a few bug fixes) to the
front line users of standard squeak for several years, since he has his
own fork to worry about.

Along comes Andreas and takes over with out a by or leave and declares a
new "our" process. Then secondly where do all these folks I have never
heard of, including yourself, and I have never seen any previous
contribution to squeak get off calling it "our" process.

Lets take yourself...

Have you contributed a fix to mantis, discussed it tested it in several
images? If so great, but have you? This was the mechanism for making
small contributions in 3.10, and 3.11+ did you ever use it?
Have you taken a subsystem of squeak, and worked on it to produce a new
deliverable that can be used by users of Squeak 3.10, 3.9,3.8 Pharo and
cobalt and perhaps other images.
Have you offered to join a team maintaining a significant part of
squeak, or a significant subsystem?
Have you written any significant loadable library for squeak?
Have you even joined the release mailing list and offered your services?

For example, I took on the idea of replacing FileDirectory, and I have
spent what now amounts to more than couple of years working on Rio, as a
replacement to FileDirectory. I also took on the idea of making
Universes workable, and maintaining MC. All of these are contributions
to the future of squeak that the"trunk" process has summarily dismissed.

Where is your contribution, for you to call it "our" process? If your
name is not Bert, Matthew, Andreas, Igor, Nicholas Cellier, David Lewis,
or Edgar, then you probably do not pass the contributor test I outlined
above, and really you shouldnt even be involved in this conversation at
all until you have earned your stripes.

If you think that joining Andreas hacking away in trunk is of any use to
anyone, then good luck to you. All I see coming for me is an enormous
porting process looming over the horizon, and a wait of 2 years for all
the packages I am depending on to get around to updating to use it and
so I will probably just stick with 3.10 for myself because no path of
planned evolution is being defined. This kind of effort to generate this
kind of discontinuity would be far better targeted at Squeak 5.0/Spoon.

The trunk is a pit of unmanaged, unplanned, haphazard activity that has
no thought behind it and is useless to the majority of current squeak
users, and it continues to treat the image as a monolithic entity. We
are back where we started in the hands of a privileged few people. It
was the very fact that the community has reached a propensity to fork
that was the signal to us that some new approach was needed.

It has been the bane of all release teams, that discussions on
squeak-dev are known to continuously strain the release team, to the
point where people in the past have been used abused and burned out.
This is what resulted in Pharo leaving in the first place, and it
appears that no one, least of all the board learnt this lesson. Matthew
and I instituted a single release team mailing list for a reason (it
appears that the board has reinstated the opposite policy without
discussing this with anyone)

What should have happened is that all emails pertaining to the next
release should have been deferred to the release mailing list, where a
proper informed discussion including all the pertinent information,
could take place with all the genuinely relevant people (without these
squeak-dev lurkers) prior to making autocratic decisions.

As a result of events surrounding "the trunk" and its "management". I
have decided to withdraw from making public contributions to squeak.

This decision has been made entirely due to the actions of the board,
and the downright disrespectful behaviour of some of its members.  In
particular no efforts were made to contact me in the 8 weeks preceding
the announcement of this "new" (exactly the same mindset as before)
process. Subsequently I have asked the board to discuss their terms of
engagement, and since I have not had any sign of movement on this, I
have had enough. I feel that way I have been treated is simply not
acceptable.

For others seeking to contribute to squeak, I think you should think
very carefully about wasting your time in such a fragile and fickle
community. What we have observed in the past few weeks is that the whole
regime can be turned on a sixpence, it is easily swayed by whatever is
the next email that arrives in squeak-dev, on whatever topic any
uninvolved newbie wants to wax lyrical about.

I naively thought that the board was elected to provide a stabling
influence, since it is in a position to provide a longer term strategy
and thinking. However in practice the opposite appears to be the case,
since the board is just as capable of being fickle, except they go
further and they vote on their fickle decisions to start new bandwagons.
The downside being that the board being an authority figure results in
smashing up all the other wagons in the process, even the ones that it
helped to build.

Perhaps Tim and I should go for a beer together.

best regards

Keith