[Election] ...is soon upon us! Last day info

> Hi all!
>
> Ok, so tonight at 18.00 UTC the actual voting period starts. It goes  
> like this:
>
> - 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

>> Hi all!
>>
>> Ok, so tonight at 18.00 UTC the actual voting period starts. It goes like
>> this:
>>
>> - 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
> noise.
>
> 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:
>
> http://squeakboard.wordpress.com/our-mission/
>
>> 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
> implications.
>
> 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
>> tasks,
>>
> 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
>> series,
>>
> 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
> anything.
>
> (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
> down)
>>
>> 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.
>
> regards
>
> Keith
>
>
>
>
>
>
>

> Keith,
> 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
> participating people.
> Otherwise, you fail, no matter how noble your causes are.
>
> Cheers
>
> Nicolas

>
> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>
>> Keith,
>> 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
>> participating people.
>> Otherwise, you fail, no matter how noble your causes are.
>>
>> Cheers
>>
>> Nicolas
>
> I think contributing patches to mantis was simple enough

> On Wed, 10 Mar 2010, keith wrote:
>
>>
>> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>>
>>> Keith,
>>> 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
>>> participating people.
>>> Otherwise, you fail, no matter how noble your causes are.
>>>
>>> Cheers
>>>
>>> Nicolas
>>
>> I think contributing patches to mantis was simple enough
>
> That's true, but most of them were never integrated, because:
> - the integrator has to have deep knowledge about the issue, the patch and
> the system (this was much harder than now, because now the creator of the
> patch can integrate it most of the time. IMHO this is the weakest point in
> Pharo's contribution process, besides the lack of contributors.)
> - patches to a "fixed point" can conflict with each other making integration
> even harder
>
> Also fine grained "cherry-picking" is not a good idea, because you just
> can't predict how the patches will interact with each other.
>
>
> Levente
>

> 2010/3/10 Levente Uzonyi <[hidden email]>:
>> On Wed, 10 Mar 2010, keith wrote:
>>
>>>
>>> On 10 Mar 2010, at 13:39, Nicolas Cellier wrote:
>>>
>>>> Keith,
>>>> 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
>>>> participating people.
>>>> Otherwise, you fail, no matter how noble your causes are.
>>>>
>>>> Cheers
>>>>
>>>> Nicolas
>>>
>>> I think contributing patches to mantis was simple enough
>>
>> That's true, but most of them were never integrated, because:
>> - the integrator has to have deep knowledge about the issue, the patch and
>> the system (this was much harder than now, because now the creator of the
>> patch can integrate it most of the time. IMHO this is the weakest point in
>> Pharo's contribution process, besides the lack of contributors.)
>> - patches to a "fixed point" can conflict with each other making integration
>> even harder
>>
>> Also fine grained "cherry-picking" is not a good idea, because you just
>> can't predict how the patches will interact with each other.
>>
>>
>> Levente
>>
>
> Yes, I personnaly posted several uncompatible patches, so "manual"
> review is necessary, and the image still is an efficient support for
> that.
> At the end, a different patch would be needed for squeak 3.9, 3.10,
> trunk or Pharo, and as long as the code is on mantis, it is dead.
> Maybe using automation to make it live - as Keith started - could
> help, but under express condition to have good test coverage.
> Also, automation is only good for detecting the issues, not really for
> solving them, so I'm not fully convinced for the Kernel.
> I presume automation should work better with packages, but beware of
> combinatorial if you want to assert groups of packages...
>
> Nicolas
>

>>>I think contributing patches to mantis was simple enough
>>>
>>
>>That's true, but most of them were never integrated, because:
>>- the integrator has to have deep knowledge about the issue, the patch and the system (this was much harder than now, because now the creator of the patch can integrate it most of the time. IMHO this is the weakest point in Pharo's contribution process, besides the lack of contributors.)
>>- patches to a "fixed point" can conflict with each other making integration even harder
>>
>>Also fine grained "cherry-picking" is not a good idea, because you just can't predict how the patches will interact with each other.
>>
>>
>>Levente
>>
>
>I don't think you are understanding, we had already been using this process for over 2 years. It did work, and it worked for more than one image simultaneously, as demonstrated by LPF. It also worked for ALL the packages in Sake/Packages, not just for the kernel.
>
>The bare minimal step forward 3.10-build image had 17 fixes in it, it demonstrated the concept well. The test script that was being used to generate an example 3.11-alpha had over 100 fixes in it. My production images have a fair few too. We didn't have a problem with this process at all. We were producing tools to automate and speed up this process, to be repeated on a monthly cycle. The work that went into that 3.11 script was then repeated in trunk, so I wasted my time on it.
>
>If you are stupid enough to try and integrate more than 500 fixes per month then of course you will have conflicts that are a problem. However 200-300 is perfectly doable per month. We had 100 just by selecting Nicolas' fixes.
>
>The main goal of the fixes is not to fix things per-se but to carefully re-architect things so that they become modules that can be worked upon and fixed offline, by separate individuals or teams.
>
>"trunk" hasn't even split up "System", which was the first thing that needed doing if you believe in modularity. We also reorganised all of the tests so that they go with the thing they are testing and are unloadable and loadable.
>
>The trunk process is the opposite of this, in spirit because it doesn't even consider having a package management solution important enough to do first.
>
>The fact that we didn't publish an image, was simply because the bob-process had not been completed up to the automated testing point, and that was our actual deliverable. Not that the automated build process using mantis didn't work. As I said it had already been proven.
>
>One weak point in the plan is the lack of discipline within the community to use mantis well, and the fact that the whole system did not work offline, and was relatively fragile as a result. But part of the bob-process plan was to provide an offline code cache. Introducing trunk, undermined mantis as a source of good code, for any purpose, even supporting legacy images, and rendered the monthly bob release cycle process useless overnight.
>
>K

> At 7:01 PM +0000 3/10/10, keith apparently wrote:
>>>>I think contributing patches to mantis was simple enough
>>>>
>>>
>>>That's true, but most of them were never integrated, because:
>>>- the integrator has to have deep knowledge about the issue, the patch and the system (this was much harder than now, because now the creator of the patch can integrate it most of the time. IMHO this is the weakest point in Pharo's contribution process, besides the lack of contributors.)
>>>- patches to a "fixed point" can conflict with each other making integration even harder
>>>
>>>Also fine grained "cherry-picking" is not a good idea, because you just can't predict how the patches will interact with each other.
>>>
>>>
>>>Levente
>>>
>>
>>I don't think you are understanding, we had already been using this process for over 2 years. It did work, and it worked for more than one image simultaneously, as demonstrated by LPF. It also worked for ALL the packages in Sake/Packages, not just for the kernel.
>>
>>The bare minimal step forward 3.10-build image had 17 fixes in it, it demonstrated the concept well. The test script that was being used to generate an example 3.11-alpha had over 100 fixes in it. My production images have a fair few too. We didn't have a problem with this process at all. We were producing tools to automate and speed up this process, to be repeated on a monthly cycle. The work that went into that 3.11 script was then repeated in trunk, so I wasted my time on it.
>>
>>If you are stupid enough to try and integrate more than 500 fixes per month then of course you will have conflicts that are a problem. However 200-300 is perfectly doable per month. We had 100 just by selecting Nicolas' fixes.
>>
>>The main goal of the fixes is not to fix things per-se but to carefully re-architect things so that they become modules that can be worked upon and fixed offline, by separate individuals or teams.
>>
>>"trunk" hasn't even split up "System", which was the first thing that needed doing if you believe in modularity. We also reorganised all of the tests so that they go with the thing they are testing and are unloadable and loadable.
>>
>>The trunk process is the opposite of this, in spirit because it doesn't even consider having a package management solution important enough to do first.
>>
>>The fact that we didn't publish an image, was simply because the bob-process had not been completed up to the automated testing point, and that was our actual deliverable. Not that the automated build process using mantis didn't work. As I said it had already been proven.
>>
>>One weak point in the plan is the lack of discipline within the community to use mantis well, and the fact that the whole system did not work offline, and was relatively fragile as a result. But part of the bob-process plan was to provide an offline code cache. Introducing trunk, undermined mantis as a source of good code, for any purpose, even supporting legacy images, and rendered the monthly bob release cycle process useless overnight.
>>
>>K
>
> I personally used Keith's process before 'trunk' was instituted, to build a Squeak-dev image from 3.10.2, using Damien's previous scripts, via Installer, Sake/Packages and Bob the Builder. This proved out the overall process to me, and if *I* could do it, then surely anyone else could similarly have done so.
>
> Ken G. Brown
>
>

>>>
>>> I think contributing patches to mantis was simple enough
>>
>> That's true, but most of them were never integrated, because:
>> - the integrator has to have deep knowledge about the issue, the patch and
>> the system (this was much harder than now, because now the creator of the
>> patch can integrate it most of the time. IMHO this is the weakest point in
>> Pharo's contribution process, besides the lack of contributors.)
>> - patches to a "fixed point" can conflict with each other making
>> integration even harder
>>
>> Also fine grained "cherry-picking" is not a good idea, because you just
>> can't predict how the patches will interact with each other.
>>
>>
>> Levente
>>
>
> I don't think you are understanding, we had already been using this process
> for over 2 years. It did work, and it worked for more than one image
> simultaneously, as demonstrated by LPF. It also worked for ALL the packages
> in Sake/Packages, not just for the kernel.

>
> The bare minimal step forward 3.10-build image had 17 fixes in it, it
> demonstrated the concept well. The test script that was being used to
> generate an example 3.11-alpha had over 100 fixes in it. My production images
> have a fair few too. We didn't have a problem with this process at all. We
> were producing tools to automate and speed up this process, to be repeated on
> a monthly cycle. The work that went into that 3.11 script was then repeated
> in trunk, so I wasted my time on it.
>
> If you are stupid enough to try and integrate more than 500 fixes per month
> then of course you will have conflicts that are a problem. However 200-300 is
> perfectly doable per month. We had 100 just by selecting Nicolas' fixes.

>
> One weak point in the plan is the lack of discipline within the community to
> use mantis well, and the fact that the whole system did not work offline, and
> was relatively fragile as a result. But part of the bob-process plan was to
> provide an offline code cache. Introducing trunk, undermined mantis as a
> source of good code, for any purpose, even supporting legacy images, and
> rendered the monthly bob release cycle process useless overnight.
>
> K
>
>
>
>

>
> As I have always said, anyone can hack at a monolithic image, that is not
> news. In fact that is the approach that got is into this mess in the first
> place. If the community wants to go in a specific direction then you have to
> plan for it, think about it and actually work on the tools you need to
> achieve it.
>
> Developing tools for 12 months, forgetting all of your goals, and going back
> to where you started, and then saying that you don't care if you never get to
> where you wanted to go, is not progress in my book.

> Developing tools for 12 months, forgetting all of your goals, and going back
>
> to where you started, and then saying that you don't care if you never get
>
> to where you wanted to go, is not progress in my book.
>
> No. Why? A failure teaching us as well (and even better) than a
> succcess. Of course, if we want to learn.
>
> Keith
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> The only failure I saw was a failure of the board to have some minimal
> standards of fairness, humility, communication and respect. Pretty sad state
> of affairs "among friends" I think.
> So having identified the failure, if you are so willing to learn how about
> fixing it, at the point of failure? i.e. the Board and its lack of protocol.
> And while we are talking about failures and fairness, whatever happened to
> Squeak 5.0 Spoon etc?
> K.
>