[squeak-dev] Morphic Text Improvements

Folks -

With our pretty new fonts, I felt the need to include some of our older
text improvements and fixes. If you update from the trunk, you will
notice that:

a) Text now has a more regular blinking insertion point instead of the
virtually invisible something before.

b) Text displayed with a non-default style always uses the correct
default font; text copied and pasted between editors with different text
styles has no strange effects on the text size.

c) The line height of empty text is correct (for example in
FillInTheBlanks - this is much more noticable with blinking cursors).

I don't expect any fallout with these changes because they've been used
quite a while and are pretty solid, but since text behavior can
sometimes have odd side effects, please keep an eye open and let me know
if you find any strange behavior.

Enjoy,
   - Andreas

On 2009-08-05 09:17, Andreas Raab wrote: Do you have this as a change set ?
This could be useful for the etoys image,

Karl

Karl Ramberg wrote:
> Do you have this as a change set ?
> This could be useful for the etoys image,

It's been on Mantis for a mere eight months:

http://bugs.squeak.org/view.php?id=7252

Cheers,
   - Andreas

Le 09-08-05 à 03:17, Andreas Raab a écrit :


Don't know if it is a problem or not but now   the menu item "Code  
font.." in Standard System Fonts menu does'nt act anymore, defaut text  
font
seems the manager....

Raymond Asselin wrote:
> Don't know if it is a problem or not but now   the menu item "Code
> font.." in Standard System Fonts menu does'nt act anymore, defaut text font
> seems the manager....

Now fixed. It was a side effect from switching to using ToolBuilder.
Just the kind of issue I was looking for. Thanks for reporting it.

Cheers,
   - Andreas

Le 09-08-08 à 12:33, Andreas Raab a écrit :

I think that the Trunk is way cool....

Raymond Asselin wrote: And I dont

Keith

Le 09-08-08 à 14:20, Keith Hodges a écrit :

> Raymond Asselin wrote:
>>
>>
>> I think that the Trunk is way cool....
> And I dont
>
> Keith
>

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 and an improvement except that we lost  
daily interactivity 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, but  
we still
have to find how and when and where in our process.
I found very interesting the video about the 'openBSD' model, and  
think we must go in that direction.

2009/8/8 Andreas Raab <[hidden email]>:
> Karl Ramberg wrote:
>>
>> Do you have this as a change set ?
>> This could be useful for the etoys image,
>
> It's been on Mantis for a mere eight months:
>
> http://bugs.squeak.org/view.php?id=7252
>
Andreas could you revise the following:
http://bugs.squeak.org/view.php?id=6948

especially one which starts cursor blinking after a while when
selection is changes.
And nevermind, if your change is already contain similar behavior.


> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

> 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

Igor Stasenko wrote:
Interesting. I never noticed this report. It's even older.

> especially one which starts cursor blinking after a while when
> selection is changes.
> And nevermind, if your change is already contain similar behavior.

It works similarly. What I did was delaying blinking whenever a
character gets typed so you get no blinking when you use cursor keys or
during type-in (which is similarly annoying).

Cheers,
   - Andreas

On 08.08.2009, at 22:59, Keith Hodges wrote:
> [...snip...]
> 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.

> [...snap...]

I promised to you privately to bring this up in this week's board  
meeting. I did, and we discussed it (alone, alas, as you refused to  
join the meeting). The minutes went not really into detail, but it's  
the second paragraph. The gist was that we do watch how the discussion  
and contributions here unfold.

In the "8 weeks" you mention the board did speak to the Release Team  
leader, which is Matthew. Maybe the release team list would have been  
better - something to keep in mind for the future (or maybe release  
discussion should happen on squeak-dev, we are too small a community  
for too many lists).

The fact is that we did talk to the Release Team, but could still not  
get a coherent picture of where the release actually was. The new  
process you developed did certainly not get much traction in the  
community. Perhaps it is too alien - as I said before, people do need  
time to change their habits. And they might still adopt it, the trunk  
model is not really in conflict with automatic image building and  
testing, as you well know.

But we felt there needed to be a way to make contributing simple, and  
have visible progress. The trunk model is a way to enable people to  
again participate in the Squeak development process, and that seems to  
work.

It's still not clear how an actual release will be derived from the  
trunk. We were discussing it in the Board meeting, and opinions  
differed. So discussion will continue, and we're hoping for ideas to  
come from the community.

I for one would love to have automatic image building from the trunk,  
and simply declare one of the automated builds to be "the one", after  
an appropriate time of code slush and code freeze of course. But many  
other models are possible, and you, as anyone else, is invited to  
discuss them.

- Bert -

Le 09-08-08 à 16:59, Keith Hodges a écrit :

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

I don't speak for anybody, I speak for myself.
If you are a fish you are at ease in water, but I'm not a fish
so for every new tool someone introduce I must learn to use it.
As I'm not born in the fluid of Smalltalk, and as I learned by myself  
what I know
about Smalltalk, never saw a 'living' Smalltalker working infront of me,
I'm not always as confident as I should and so don't take too much  
place.
Add to this that I'm not a native english man so this doesn't help
to participate fully in a team.


I know and agree that your contributions where and are important.

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

It seems to me that you reproduce what you reproach....
The number of time somebody went to tell other "if you don't  
post...you don't speak"
on this list, at different time, is simply too much...point.
Please don't forget that we are on the net...it is open...I mean "OPEN"
so we must go with it...

I can tell you that I agree with some of what you say here...and also  
the automatic building process...but I think
that the blood whas not circulating anymore in the body so it was  
imperative
to reactivate it, and IMO the Trunk can slowly reactivate the blood  
circulation
of Squeak.
I expect that  we will collectively -- at "open" community pace --
  - define a path of evolution for Squeak
  - precise what the porting process will be
  - how to reintegrate some *caution here* aspects of other fork
  - how to rejoin together when possible...
I add to this one of my own view:

  - for the rest of us : I mean not only system developper, not only  
application developper but also user of Squeak.
I say this because differents forks used to be what I call  
"Specialised Fork" around applications (DabbleDB,Seaside),
around research team (Pharo), around refactoring (Cuis) etc... Also  
seeing users only on the side of Etoys is an error
there are users that use Squeak as a dayly toolset and who program in  
Squeak without building "Commercial applications".

User of Squeak have their place, and can speak. They are more than  
just (squeak-dev lurkers).
Are tell differently, they are squeak-dev lurkers at moment, depending  
of what is discussed on the table, or what they can
bring.


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

I understand your decision...but it is a lost from the community point  
of view.

> 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 recognise that it appears like that...

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

The board is an elected board and I'am confident that they look for  
the better.

Bert,
> I promised to you privately to bring this up in this week's board
> meeting. I did, and we discussed it (alone, alas, as you refused to
> join the meeting).
You make this sound as though this is my fault that I will not attend
the board meeting, au contraire. I stated clearly to you that I would
not attend because I feel intimidated in such a forum, when there are
people on the board who have already demonstrated (publically with
witnesses) an ability to be condescending and rude, so I do not feel
like putting myself in a position to be abused thank you very much.

It is because the board has failed to act in a gentle overseeing and
supporting manner, which is what I believed that the board was intended
to be, that it is necessary for the board to establish their terms of
engagement FIRST before any other discussion can take place.

Individual members of the board have been rude and unprofessional, and
members that were elected to liaise and supervise have done nothing of
the sort. How come the board has been in existence for several years and
yet has not felt a need to interfere in anything at all before. They
even let the previous release team leader disappear for months and no
one dreamed of taking over without speaking to him personally first.

Lets be clear, you can leave all your self-justification aside over the
release issue for now because it is not relevant. The way this was
handled has been an unmitigated disaster. This is the issue I asked you
to discuss at the board meeting.

I asked you to discuss the fact that the board needs to establish its
terms of reference, and its role, so that this doesn't happen again.

Issues such as whether a board member has a remit to interfere with an
appointed team and to what extent. Should board members participate in
the teams that they are liaising with or should they run the teams they
supervise? (If the later is the case then the team leaders should be on
the board by default) Whether a team can be sacked without being told
they are sacked, or whether there is any protocol at all, and under what
circumstances should a board member be required to step down. You were
all elected to liaise and supervise not to cause agro in any shape or form.

Did you discuss this at your meeting?

By default the current set up enables any existing team leader to be
subjected to additional "leadership" from a newly elected board
member.   This then puts any potential team in the position of having
two leaders, which then puts unfair tensions on the team. Two many cooks
will spoil the broth, its a foregone conclusion.

When I said that 3.10-build was called 3.10-build I meant it, I didn't
need Andreas to cause, confusion among other contributors. He should
have spent time and effort in his elected role recruiting support for
the existing team, and the existing jobs list, instead he set out to
compete from the beginning. As I said before the result of this approach
was a forgone conclusion; doomed from the start.

Why have you not asked Craig to clarify the process for contributing to
squeak 5.0. Craig told the board that squeak 5.0 would be released 11
months or more ago, where is the visibility and the agro there? Seems a
bit like double standards to me.

If you want a team to make regular reports , then ask them, don't just
make this up as you go along. You are not elected to make brash and
in-informed decisions, and Andreas was not elected to take over the
release process but to motivate it and to move it forward. The only
motivation I got from Andreas was him telling me that 3.10-build should
be called 3.11-alpha,  that's not motivating, that's called not listening.
> The minutes went not really into detail, but it's the second
> paragraph. The gist was that we do watch how the discussion and
> contributions here unfold.
>
> In the "8 weeks" you mention the board did speak to the Release Team
> leader, which is Matthew.
> Maybe the release team list would have been better - something to keep
> in mind for the future (or maybe release discussion should happen on
> squeak-dev, we are too small a community for too many lists).
So why has the board made 6 yes 6 lists for releases? see
lists.squeakfoundation.org , when we had consolidated them down to 1.
> The fact is that we did talk to the Release Team, but could still not
> get a coherent picture of where the release actually was.
Total rubbish, some of those attending the board meeting knew full well
that I had started documenting the process, because it was essentially
complete, using videos on vimeo so the coherent picture for which you
were allegedly looking was literally taking shape at the time you were
meeting, and would have been a couple of days away at the time. I was
making the videos in order to make sure everything was easily visible
and working before our scheduled slot on industry misinterpretations
(never was there a more aptly named podcast).

You didn't make any effort at all, I was in irc all of the time for all
of the 8 weeks I mentioned, and Ken Brown managed to get a clear picture
of what was going on with a little effort.

Remember the board is elected to liase and advise so where is this
liasing? One discussion with matthew at a time when he was having self
doubts ("why dont we just use pharo") really doesn't count as liason. I
might be wrong but a liason includes an ongoing dialog.

By the way, since Randal had stolen Matthew to work on 4.0, it doesn't
wash that you asked Matthew about the status of 3.11 when at the board's
behest he was working on (or supposed to be) 4.0 and the relicencing at
the time.
> The new process you developed did certainly not get much traction in
> the community.
Then it is your job to encourage and facilitate that traction, not
destroy it. I can't do everything.
In actual fact all that board members did was grumble, argue about, and
generally confuse the release numbering.
Oh and as I pointed out about they acquired the 3.11 team "leader" to
work on 4.0.
> Perhaps it is too alien - as I said before, people do need time to
> change their habits.
How is the process that was used for 3.9 and 3.10 too alien, (submit
your fixes to mantis) we have been using it for years?
> And they might still adopt it, the trunk model is not really in
> conflict with automatic image building and testing, as you well know.
Yes it is, because it moves development to a moving target, not a number
of discrete steps based upon fixed targets that give us a migration
path. I can't do anything with trunk, its only use is in building an
image based upon trunk, but I dont want an image based upon trunk, I
want an image based upon 3.10. The whole point is to get away from
building one image, and to facilitate all the forks to move forward. I
cannot harvest trunk into my production images, because the knowledge of
the component parts of whatever is in trunk has not been packaged
appropriately. This is a management decision, but trunk doesn't have any
management.

3.10 + process = 3.11
3.11 + process = 3.12
etc
> But we felt there needed to be a way to make contributing simple, and
> have visible progress.
We had a way, we had just automated the mantis contribution process. You
can see what status each fix is at in colour, and we were very close to
automated testing go live.

You moved the goal posts, since the existing proposal stated that the
3.11 effort was not about producing an image. Again we are back to the
board's terms of engagement, can they pull the rug out from a team like
that, without requiring a competing proposal to be written, published,
discussed and voted on according to a protocol.
> The trunk model is a way to enable people to again participate in the
> Squeak development process, and that seems to work.
You = the board didn't even give matthew or I access to
squeakfoundation.org. We already had a trunk on squeaksource.com/311
What was new about trunk? Nothing, but you didn't even ask "do we
already have a trunk"?

Come on its not hard, I am in irc all the time, you didn't even try. At
what point did Andreas think, eureka, we need a trunk repository, I
wonder if we already have one, I know I will ask?

But you have no management, no vision, no goals, or planning in place.
Each initiative should be undertaken in in separate set of repositories,
not one confused and unmanaged repository. You have visibility, true,
visible confusion, and a single image as a result. ALL the work you put
into trunk will have to be redone from scratch by someone else, in
exactly the same way as all the work the pharo guys have done will have
to be sifted through and harvested manually into squeak. In the same way
as all the work that Edgar did on his SLII he is now having to sift
through and harvest into trunk. All that trunk is doing is making more
work for someone else by making the discontinuities between steps bigger
and the documentation of the steps worse.  In relation to our stated
goals, each contribution to trunk is a step backwards and further away
from our goal.

Contrast this with the existing 3.11 process, all of the essential
3.10-build fixes were packaged, documented, and automatically loadable
separately on mantis, and as a result the majority of them are in pharo
already. Yes we contributed to the pharo process (its a shame that they
havent reciprocated the favour) So for example LPF doesnt need any fixes
to load into pharo.  Every fix that pharo adopted from the 3.11 in-tray
is common code that brings the two forks closer together. This was only
achievable because each fix is managed as a separate deliverable, rather
than being thrown into trunk by some random unknown contributor. You
have replaced a process that works towards the stated goals with no
process at all.
> It's still not clear how an actual release will be derived from the
> trunk. We were discussing it in the Board meeting, and opinions
> differed. So discussion will continue, and we're hoping for ideas to
> come from the community.
What's that got to do with the board? If the board wants to discuss this
then it should join and contribute to the release team who have to do
the work. For years the board has done nothing, now all of a sudden it
thinks it can suddenly be the release team, and make release team
decisions without actually doing any of the work.

How to produce a release is up to the release-team and the leader of the
release team, which you don't have anymore.  How is it fair that Andreas
is unsackable because he is on the board, and I am not. So if Andreas is
the new release team leader then he should step down from the board, due
to a conflict of interests since the board should retain impartiality.

You aren't going to get any ideas from the community, only Andreas knows
what Andreas is going to do, and Andreas hasn't got a manager, nor is he
working to any vision, set of values, or goals.
> I for one would love to have automatic image building from the trunk,
> and simply declare one of the automated builds to be "the one", after
> an appropriate time of code slush and code freeze
What happened to our plan of stable and unstable builds.
> of course. But many other models are possible,
No they aren't possible, because you have imposed a single model on the
community, that model is Andreas now does what he wants to do, and he
doesnt answer to anyone.
> and you, as anyone else, is invited to discuss them.
I am discussing them, and I am saying that the "single" trunk model
undermines everything else we have achieved so far. If I mark a fix in
mantis, how do I know what that fix's status refers to? It has to be a
fix relative to previous versions, not trunk.

Until someone is appointed to actually manage what is going on, and to
specify deliverables in a usable form for the community we are scuppered.

I say again just in case you missed it again, I am not making any
further contribution to the squeak community, until the board has some
articles which define its articles and terms of operation, with some
form of protocol and complaints procedure.

Essentially as I pointed out before, having a position where there are
two leaders for one team is a recipe for disaster, you need to fix that
recipe urgently.

best regards

Keith

Keith Hodges wrote:
I'm not sure who exactly you are referring to in the above as being
condescending and rude, but if you mean me, I have offered to stay away
from such a meeting if that makes it acceptable to you. The offer is
still on the table, you only need to accept it.

If it's not me, then you'll have to be explicit about who you think
would be acceptable in such a discussion and who wouldn't.

Cheers,
   - Andreas

Hi Keith,

Dear Elliot,

I do understand about documentation. I might be a little facetious if I
point out that "Installer" was probably the first piece of code
published for squeak that I had ever seen any documentation for, and
that was only because I wrote it.

I mentioned the videos because they serve a couple of purposes, firstly
they show that something is being worked upon, and the process of
putting together the video is a helpful quality gate.

Recent events are resulting in a change in priorities for me. I am
restoring my 1977 camper van, which looks something like this
http://www.newlandercamper.co.uk , and I am returning to full time
ministry, back to the real world from whence I came. Squeak was a
temporary bit of escapism for me. Yesterday I had a visit from an
ex-gangster who was beaten up by 11 guys with baseball bats, spent 7
months in a coma, 3 years in hospital, had to relearn how to walk and
talk, I figure folks like him need my time and expertise more than
squeak does.

Squeak-core is now at the bottom of my priority list, and while the
board is in denial, it might as well stay off the list altogether.

Keith

Keith Hodges wrote: Hello Keith

you mention your Installer documentation.
I would like to ask you for the main entry point into the "Installer"
documentation.

http://www.google.com/search?hl=en&safe=vss&client=firefox-a&rls=com.ubuntu%3Aen-US%3Aunofficial&hs=nLH&q=%22Keith+Hodges%22+Installer&btnG=Search&aq=f&oq=&aqi=

(search for  
    "Keith Hodges" Installer
)

gives 1190 hits.

It is surely not a bad idea to take a break from time to time. It would
be nice to leave some pointers behind you, so that other people might
take it on later if they think it is useful (which it probably is - it
was maybe just not the right time yet).

This trunk based system depends on having strong developers in the core
team and involves more manual work. However if people are doing it then
it is fine. And it is probably better for a major overhaul as Andreas,
Juan and Bert and others now have started. This is just a general
impression. I did not follow the development closely in the last two or
three years. However I am happy that they work on a 3.11 version which
really looks great with the new font system and which will keep the
'original flavor'.

It would be nice to see you contributing again in the future.

Regards
Hannes

On Thu, Aug 13, 2009 at 03:13:14PM +0000, hannes.hirzel wrote:
> you mention your Installer documentation.
> I would like to ask you for the main entry point into the "Installer"
> documentation.

http://installer.pbworks.com/Installer

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/