[squeak-dev] Release process
eliot.miranda at gmail.com
Thu Aug 13 02:40:13 UTC 2009
On Sat, Aug 8, 2009 at 7:39 PM, Keith Hodges <keith_hodges at yahoo.co.uk>wrote:
> > 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).
Personally I find videos more than unsatisfactory. They require I spend the
entire length of the video in passive viewing of the material. The material
is unsearchable and effectively unindexable ("scroll to about 5 minutes in"
is not a URL). Whereas a couple of well-written web pages are terrific. A
good example is the Pharo pages as mentioned by Serge in the Inbox thread,
Here are the links:
If someone could document your process in this form I expect a lot of the
current miscommunication would conclude. I had made an offer to you to help
produce such documentation but realistically I'm not able to as my plate is
too full, for which I apologise. But if you or anyone else could try and
produce something analogous to the above, concise, comprehensible and usable
as a script, IMO that would really help.
> 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
> 3.10 + process = 3.11
> 3.11 + process = 3.12
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev