[squeak-dev] [Election] ...is soon upon us! Last day info
nicolas.cellier.aka.nice at gmail.com
Wed Mar 10 13:39:07 UTC 2010
I won't try to distinguish what I consider true and false assertions
here, and will stay positive.
It's good that you have a vision, and for sure a vision larger than
squeak-trunk patch process.
But... You have to invent a process simple enough to attract
Otherwise, you fail, no matter how noble your causes are.
2010/3/10 keith <keith_hodges at yahoo.co.uk>:
>> Hi all!
>> Ok, so tonight at 18.00 UTC the actual voting period starts. It goes like
>> - Around 18.00 UTC tonight you will get an email from the CIVS voting
>> system with a link in it. You have one week to click on that link and vote.
>> - If you realize that you never got this email it can be because of mail
>> problems or that you aren't on the voter list. Send me an email in either
>> case and I will try to sort it out.
>> - If you voted last year you are already on the list.
>> I will accept new voters during the whole voting week! I will also do my
>> best to fix any issues with ballots gone missing in the SMTP jungle.
>> regards, Göran
> Dear All,
> for the record I am not voting, since the squeak board is now irrelevant
> The board cannot even manage a mission statement and maintain that (see
> below), terms of reference are a distant hope, the idea of this farce
> becoming an official legal entity, yet not seeing the need to have any
> constitution or rules at all for how it conducts itself, would be a joke of
> immense hilarity if it wasn't serious.
> Here is the mission statement as advertised:
>> The Squeak Oversight Board coordinates the community’s open-source
>> development of its versatile Smalltalk environment.
> Ok let examine this line, "co-ordinates". This involves doing some actual
> work, talking to people, discussing things weighing up ideas, and making
> considered informed decisions. "Co-ordinates" means, that the board doesn't
> actually "Do Stuff" but it relies on others to do stuff which it then
> co-ordinates through helpful advice perhaps.
>> To that end, we are increasing our visibility
> Cant argue with that.
>> within the community through better communication,
> In the introduction of "trunk", there was zero repeat ZERO pre discussion
> about the idea with those that it effected. All existing avenues of
> communication were ignored, and existing best practice was ignored such as
> using a "release mailing list" as used by the board-endorsed "release team".
> Also specific requests for preferences to communicate on the release mailing
> list were ignored, when this had actual practical and financial
> In a world of modern communications when we have irc and skype and we are on
> the other side of the world and I get free calls to anywhere in the world
> 24/7. But does the board know how to use email? Andreas says that perhaps
> this was a mistake, however it wasn't his mistake, it was the board's
> mistake, to allow a new direction to be mandated without requiring a
> proposal, a consultation and a vote of sorts over a period.
> As a member of the community I had to follow a formal procedure to satisfy
> the board. Members of the board are exempt from any such formality. Thus it
> is now perceived by some as a requirement to have a position on the board to
> be heard. If you have a commercial interest in squeak, if you do not have a
> position on the board, you do not have an equal representation as compared
> to others who do have a position on the board.
> The board should be strictly impartial in relation to commercial interests,
> while it is not, it is not trustable.
>> improving the release process,
> The release process, is the bit which takes an image, adds some fixes,
> updates packages to their latest versions, adds licensing, documentation,
> sets the version number, and zips up the result.
> I have just witnessed Ronald, or whatever his name is ;-) do this for Squeak
> 4.0, and it was done Manually, exactly the same as every other release, and
> the process itself took at least 3 weeks, when an automated process (which
> we already had) would take 3 minutes.
> So much for improving the release process. Nothing has changed.
>> joining the Software Freedom Conservancy, enabling Teams to achieve their
> This is comical. How did the board "enable" me to achieve my task. To do
> this they would have to communicate (see first paragraph) They just
> undermined everything I had done, then and told me I don't have enough
> Charisma, and "the end justifies the means".
>> and integrating contributions from collaborating groups (for example,
>> Pharo, Etoys, and Croquet).
> "integrating contributions", to me means that we treat all of these groups
> as part of the community and try to create processes that work, and manage
> some of it in common between them, and we act for them as an enabler.
> Does the new "trunk" process introduced by the board this year do this? No
> it doesn't it, it is exclusive to squeak itself as a fork. It just enables
> more people to contribute to squeak as its own fork, speeding up the process
> of diversion between forks, It discourages the development of features in
> common with other forks, specifically it does not treat the development of
> features as distinct load-able entities that are integrated.
> Recent statements by board members have indicated that the board doesnt aim
> to represent anyone else other than the squeak fork, whereas before we had a
> feeling of responsibility for providing tools and services to benefit all of
> our many "prodigy".
> The board continues to treat previous releases as abandon-ware. We don't
> even look after our existing users.
>> Our goals for this year are a **clear** release process for the 3.x
> Trunk doesn't have any clear indication of what will or will not be in it.
> it doesn't have any development plan or timeline
> it doesn't have any packaging system where stuff can be clearly organised.
> it doesn't have any automated testing
> it doesn't have any automated release process.
> it doesn't adopt any best practices such as XP, release early and often so
> releases are not time boxed, everything is far from clear.
>> a license-clean Squeak 4.0 release,
> This was a goal. How long ago? If I had to manually rewrite every method
> effected 3 times, it could have been done quicker. The problem with this
> goal was that everyone talked about it, no one on the board actually did
> (apart from asking the 3.11 release team leader to do the job on squeak
> 4.0, without asking the release team, and consequently leaving us a man
>> a solid legal foundation,
> The board members have resisted all attempts to suggest that a constitution
> is a necessary thing. Without it the board has no identity in and of itself,
> it is merely a collection of randomly selected, "charismatic" individuals.
> How you would achieve becoming a legal entity without any rules at all is
> anyone's guess.
>> and a draft programming interface for exchanging code between systems.
> No sign of this.
> (except I have developed it recently)
>> With these, we believe the community will be more effective in developing
>> for itself and in introducing the system to newcomers.
> I agree if the board actually did any of these things it might. But at the
> moment they are still patting themselves on the back saying what a great
> "trunk" process we have got, and what wonderful charismatic leaders we now
> have. When it is the opposite process of what is needed if you actually sit
> down and think about the problem as a whole.
> Anyone can hack a new image, but is the process itself capable of acheiveing
> what we want(ed) to achieve. Given that package management is left to be an
> after thought leads me to think not.
>> Please note that this is a work in progress and we appreciate any comments
>> or suggestions that you may have.
> This is my comment.
> Now for my suggestions:
> If you have a commercial interest in developing with squeak, you will be far
> better off taking control and forking the image for yourself, maintaining
> your own branch. So at least you have the level of control needed to
> maintain the required stability, and the image you use will be maintained
> (by you).
> Working towards this goal, of having control over your own image,
> individuals and groups who want to help will publish innovations in a
> separately managed load-able form, that are not tied to any one image.
> When this mechanism is in place, none of the forks is any different to any
> other fork, each is merely a configuration of loaded packages on one or many
> starting points.
> When the tools are available such that the level of control you have over
> your own image, is higher than the level of control you have over the image
> you are given by the board. The board in its current "glorified release team
> form" becomes irrelevant.
> If Kent Beck or others of his calibre were running for the board then I
> would vote.
More information about the Squeak-dev