[squeak-dev] Release process

Keith Hodges keith_hodges at yahoo.co.uk
Sun Aug 9 02:39:48 UTC 2009


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







More information about the Squeak-dev mailing list