[squeak-dev] The role of Bob, Installer & Co.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Igor Stasenko
Guys, i can only welcome to see more such discussions, where you
trying to sort things out & between different points of view find
something on which you can both agree and move forward. Because its
really frustrating for me to see nothing else than grumbling and
unwilingness to cooperate.

2009/7/6 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 7/6/09 9:23 AM, "Keith Hodges" <[hidden email]> wrote:
>
>> Edgar made SqueakLightII over a year ago (?) and we havent even been
>> able to harvest that work into a useful form yet.
>
> I should take the same road wiser Squeaker take before.
> I also feels "kicked in the ass without any good reasons" where I was the
> facto fired from Release Team.
> Now I wish going into main stream (if I could agree on something like going
> smaller an modular and have ProcustesEnd for code + picts + sound + morph +
> etc into packages)
> That means a new PackageInfo and a modified Monticello.
>
> When Ralph pick me I said he could be good have a "Monticello summit" and
> anyway we should use .cs
> We end 3.10 with .cs and many who said was wise decision don't raise his
> voice now.
>
> Maybe you could modify Bob for writing in the updates folder ?
> First "fake .cs" as we have in 3.10 should be some similar to
>
> 7068AdvanceToThreeDotTenAlpha.cs
>
> Then  some similar
>
> 7069ConvertTo3dot10.cs
>
> And then you could go as wild you wish and Mighty Board bless, use .mcz, .cs
> , DS, MC2 , sar , .pr, .morph , .sqz (I hope no miss some kind of code
> extension which could be feeded into Squeak)
>
> All could hit our squeak updates button and see how our number rise, our
> ..image go where no Squeaker go before...
>
> At this point some Java - Windoze comes and tell you he knows more but his
> time is too precious too bother change the color of screen he don't like.
>
> Edgar
>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Randal L. Schwartz
In reply to this post by Colin Putney
>>>>> "Colin" == Colin Putney <[hidden email]> writes:

Colin> I think you guys are at cross purposes here. Andreas is trying to
Colin> minimize the overhead of contributing to the squeak.org distribution of
Colin> Squeak. Keith is trying to maximize the value of each contribution
Colin> across all distributions. The technical details don't matter much if
Colin> you don't agree on the goals.

I personally suppport lowering the barrier to entry for contributions on the
"current" Squeak, even if it means making it more expensive to backport
necessary fixes to older Squeaks.  Actually, by personally, I can also mean
"with my SOB hat on".

This is the one of the problems with the Squeak core development processes
that the Pharo team "fixed".  It's time to mainline this fix, and get that
level of activity back into Squeak proper, especially with 4.0 and legal
oversite nearly here.

It's an interesting academic goal to make a delta system that can
automatically apply patches to backrev images.  But apparently, not a very
practical system for community contribution.  Time to move on.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

keith1y
Randal L. Schwartz wrote:

>>>>>> "Colin" == Colin Putney <[hidden email]> writes:
>>>>>>            
>
> Colin> I think you guys are at cross purposes here. Andreas is trying to
> Colin> minimize the overhead of contributing to the squeak.org distribution of
> Colin> Squeak. Keith is trying to maximize the value of each contribution
> Colin> across all distributions. The technical details don't matter much if
> Colin> you don't agree on the goals.
>
> I personally suppport lowering the barrier to entry for contributions on the
> "current" Squeak, even if it means making it more expensive to backport
> necessary fixes to older Squeaks.  Actually, by personally, I can also mean
> "with my SOB hat on".
>  
There never has been a barrier to making contributions. The barrier has
been in having contributions accepted into the core by the
guru/bottleneck in charge.

Take for example my own first contribution to the betterment of squeak,
Installer. There was nothing stopping me making my contribution. I wrote
Installer in my own repository, I didn't need to use trunk. Installer
has had several re-designs on the way, "build one to throw away and all
that". Imagine if I had done that in trunk!

The barrier was in getting the release team to accept it and keep upto
date with the latest. Bob does that automatically, every build includes
the latest version of every contribution, and so contributions get a
chance to be refined over time. So everyone knows that their
contribution is going to be included. The bottleneck/guru just makes the
selection as to what is in or out. If the guru doesnt select your
contribution, you simply add your own build task as a subclass of the
guru's that does. Then everyone can see how great you contribution is
and persuade the guru to accept it. If the guru still doesnt accept it,
you can still use your own personal build for your own work.

This is how LPF came about in the first place, simply because I couldnt
rely on the release team to do what I needed to move MC1.5 forward
effectively. So I took the release process and made my own appendage
LPF, and what is now InstallerScripts.

Trunk is effectively the "common" image, and should only be containing
the integration of finished "grand refactorings" as the previous email
recommended. In which case why not integrate the competed pieces in a
planned way rather than letting people loose, in an unplanned, chaotic
and mixed up way.

So with my model, you add a task to the ReleaseAfterSqueak310 in the
Tasks repository, and when the release team hits the build button your
task can be selected for inclusion. Alternatively you can submit your
change to mantis, and if the status is set to Testing/Resolved it WILL
be included.

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Igor Stasenko
2009/7/6 Keith Hodges <[hidden email]>:

> Randal L. Schwartz wrote:
>>>>>>> "Colin" == Colin Putney <[hidden email]> writes:
>>>>>>>
>>
>> Colin> I think you guys are at cross purposes here. Andreas is trying to
>> Colin> minimize the overhead of contributing to the squeak.org distribution of
>> Colin> Squeak. Keith is trying to maximize the value of each contribution
>> Colin> across all distributions. The technical details don't matter much if
>> Colin> you don't agree on the goals.
>>
>> I personally suppport lowering the barrier to entry for contributions on the
>> "current" Squeak, even if it means making it more expensive to backport
>> necessary fixes to older Squeaks.  Actually, by personally, I can also mean
>> "with my SOB hat on".
>>
> There never has been a barrier to making contributions. The barrier has
> been in having contributions accepted into the core by the
> guru/bottleneck in charge.
>
> Take for example my own first contribution to the betterment of squeak,
> Installer. There was nothing stopping me making my contribution. I wrote
> Installer in my own repository, I didn't need to use trunk. Installer
> has had several re-designs on the way, "build one to throw away and all
> that". Imagine if I had done that in trunk!
>
> The barrier was in getting the release team to accept it and keep upto
> date with the latest. Bob does that automatically, every build includes
> the latest version of every contribution, and so contributions get a
> chance to be refined over time. So everyone knows that their
> contribution is going to be included. The bottleneck/guru just makes the
> selection as to what is in or out. If the guru doesnt select your
> contribution, you simply add your own build task as a subclass of the
> guru's that does. Then everyone can see how great you contribution is
> and persuade the guru to accept it. If the guru still doesnt accept it,
> you can still use your own personal build for your own work.
>
> This is how LPF came about in the first place, simply because I couldnt
> rely on the release team to do what I needed to move MC1.5 forward
> effectively. So I took the release process and made my own appendage
> LPF, and what is now InstallerScripts.
>
> Trunk is effectively the "common" image, and should only be containing
> the integration of finished "grand refactorings" as the previous email
> recommended. In which case why not integrate the competed pieces in a
> planned way rather than letting people loose, in an unplanned, chaotic
> and mixed up way.
>
> So with my model, you add a task to the ReleaseAfterSqueak310 in the
> Tasks repository, and when the release team hits the build button your
> task can be selected for inclusion. Alternatively you can submit your
> change to mantis, and if the status is set to Testing/Resolved it WILL
> be included.
>

Keith i putting my +100 under the above.
Your framework allows us (community) to build & evolve Squeak using
maximum inclusive fashion ever possible before.
This means, that everyone could choose own direction on what to
include into own image and what not, up to the very core details.
This is the paradigm shift from single entity (release image) ,
apporoved by a group of gurus, to a multiple entities (wide variety of
images) which single person could choose from.
And of course, what is important, that old way is still possible to
follow using your framework: Yes, it is still possible to have a guru
comittee, who takes care about 'official' squeak release.

I feel sorry that among tons of docs, detailed technical explanations,
plans and discussions, i forgot this essence of your vision.

> Keith
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

keith1y
(repost in correct thread - sorry for the confusion)

Igor,

thanks for that, I still think we will get there in the end.

>From now on, I will endeavour to work with, and encourage people to
communicate in a friendlier medium than email/irc I honestly believe
that if Andreas and I had spoken on the phone/skype this confusion etc
would never have happened.

take care

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Ken G. Brown
In reply to this post by Andreas.Raab
I would like to present my sincere congratulations to Keith for continuing to talk sense against all odds, in presenting the Squeak community with such a well thought out way forward along with the mostly working code to implement the process.

Sure, there are bound to be improvements that could be applied, and I feel that is where the SOB could have put their efforts, and not towards presenting yet another way of continuing the development processes that resulted in our current situation in the first place. In my opinion this fundamentally comes from the attitude of  'do the simplest thing that could possibly work', and not do 'the best thing in the best possible way'.

And congratulations too to Igor for apparently taking the time to understand what Keith is talking about, as shown by Igor's +100 comment below.

I am very disappointed in the current extremely short-sighted view and direction that is being taken by the SOB.

I am also extremely disappointed in the way the SOB has been treating the people involved ie Keith and Matthew mainly. Might I suggest significant improvement in the area of people skills as a high priority going forward.

Thank you Keith.

Ken G. Brown

At 1:01 PM -0700 7/6/09, [hidden email] apparently wrote:

>Date: Mon, 6 Jul 2009 21:34:11 +0300
>From: Igor Stasenko <[hidden email]>
>Subject: Re: [squeak-dev] Re: [Release] The role of Bob, Installer &
> Co.
>To: The general-purpose Squeak developers list
> <[hidden email]>
>Message-ID:
> <[hidden email]>
>Content-Type: text/plain; charset=UTF-8
>
>2009/7/6 Keith Hodges <[hidden email]>:
>> Randal L. Schwartz wrote:
>>>>>>>> "Colin" == Colin Putney <[hidden email]> writes:
>>>>>>>>
>>>
>>> Colin> I think you guys are at cross purposes here. Andreas is trying to
>>> Colin> minimize the overhead of contributing to the squeak.org distribution of
>>> Colin> Squeak. Keith is trying to maximize the value of each contribution
>>> Colin> across all distributions. The technical details don't matter much if
>>> Colin> you don't agree on the goals.
>>>
>>> I personally suppport lowering the barrier to entry for contributions on the
>>> "current" Squeak, even if it means making it more expensive to backport
>>> necessary fixes to older Squeaks. ¬ÝActually, by personally, I can also mean
>>> "with my SOB hat on".
>>>
>> There never has been a barrier to making contributions. The barrier has
>> been in having contributions accepted into the core by the
>> guru/bottleneck in charge.
>>
>> Take for example my own first contribution to the betterment of squeak,
>> Installer. There was nothing stopping me making my contribution. I wrote
>> Installer in my own repository, I didn't need to use trunk. Installer
>> has had several re-designs on the way, "build one to throw away and all
>> that". Imagine if I had done that in trunk!
>>
>> The barrier was in getting the release team to accept it and keep upto
>> date with the latest. Bob does that automatically, every build includes
>> the latest version of every contribution, and so contributions get a
>> chance to be refined over time. So everyone knows that their
>> contribution is going to be included. The bottleneck/guru just makes the
>> selection as to what is in or out. If the guru doesnt select your
>> contribution, you simply add your own build task as a subclass of the
>> guru's that does. Then everyone can see how great you contribution is
>> and persuade the guru to accept it. If the guru still doesnt accept it,
>> you can still use your own personal build for your own work.
>>
>> This is how LPF came about in the first place, simply because I couldnt
>> rely on the release team to do what I needed to move MC1.5 forward
>> effectively. So I took the release process and made my own appendage
>> LPF, and what is now InstallerScripts.
>>
>> Trunk is effectively the "common" image, and should only be containing
> > the integration of finished "grand refactorings" as the previous email
>> recommended. In which case why not integrate the competed pieces in a
>> planned way rather than letting people loose, in an unplanned, chaotic
>> and mixed up way.
>>
>> So with my model, you add a task to the ReleaseAfterSqueak310 in the
>> Tasks repository, and when the release team hits the build button your
>> task can be selected for inclusion. Alternatively you can submit your
>> change to mantis, and if the status is set to Testing/Resolved it WILL
>> be included.
>>
>
>Keith i putting my +100 under the above.
>Your framework allows us (community) to build & evolve Squeak using
>maximum inclusive fashion ever possible before.
>This means, that everyone could choose own direction on what to
>include into own image and what not, up to the very core details.
>This is the paradigm shift from single entity (release image) ,
>apporoved by a group of gurus, to a multiple entities (wide variety of
>images) which single person could choose from.
>And of course, what is important, that old way is still possible to
>follow using your framework: Yes, it is still possible to have a guru
>comittee, who takes care about 'official' squeak release.
>
>I feel sorry that among tons of docs, detailed technical explanations,
>plans and discussions, i forgot this essence of your vision.
>
>> Keith
>>
>
>
>
>--
>Best regards,
>Igor Stasenko AKA sig.


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Ken Causey-3
On Mon, 2009-07-06 at 15:36 -0600, Ken G. Brown wrote:

> I would like to present my sincere congratulations to Keith for
> continuing to talk sense against all odds, in presenting the Squeak
> community with such a well thought out way forward along with the
> mostly working code to implement the process.
>
> Sure, there are bound to be improvements that could be applied, and I
> feel that is where the SOB could have put their efforts, and not
> towards presenting yet another way of continuing the development
> processes that resulted in our current situation in the first place.
> In my opinion this fundamentally comes from the attitude of  'do the
> simplest thing that could possibly work', and not do 'the best thing
> in the best possible way'.
>
> And congratulations too to Igor for apparently taking the time to
> understand what Keith is talking about, as shown by Igor's +100
> comment below.
>
> I am very disappointed in the current extremely short-sighted view and
> direction that is being taken by the SOB.
>
> I am also extremely disappointed in the way the SOB has been treating
> the people involved ie Keith and Matthew mainly. Might I suggest
> significant improvement in the area of people skills as a high
> priority going forward.
>
> Thank you Keith.
>
> Ken G. Brown
Ken,

I appreciate you providing your point of view but I have to ask you how
you have actively participated in the development of 3.11.  I ask this
not because I don't know the answer or don't remember (which is not to
say that I do) or because I'm trying to single you out but because I'm
trying to understand the disconnect that seems to be going on.

You have to understand that when the SOB discussed this there was
absolutely no question among the seven of us that the current state of
the development of Squeak was untenable.  We have frankly been inundated
with complaints on one hand and near silence from contributors.  To see
what I mean take a glance at

 http://bugs.squeak.org/view_all_bug_page.php

If it is not already, be sure to set the project (upper right) to
'Squeak').  Note that the 50 most recent issues (any change at all will
pop an issue to the top of this list, except of course if the issue is
closed which will remove it from the default view) cover a time period
of nearly 3 months.  Dig deeper and look at the changes in that time
period and the number of people participating and you find that very
little is going on on this side of things.  And yet this is the only way
to submit a change under Keith's proposal.  Of course you could also be
directly working on Installer/Bob/MC but as far as I can tell the
community involved there is similarly small.

Can I take it that your preference now would be for us to completely
retract the changes proposed by Andreas and go back to the way things
were say 10 days ago?

Ken



signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Ken G. Brown
In reply to this post by Andreas.Raab
See comments interspersed below.

At 4:25 PM -0600 7/6/09, Ken G. Brown apparently wrote:

>On Mon, 2009-07-06 at 15:36 -0600, Ken G. Brown wrote:
>> I would like to present my sincere congratulations to Keith for
>> continuing to talk sense against all odds, in presenting the Squeak
>> community with such a well thought out way forward along with the
>> mostly working code to implement the process.
>>
>> Sure, there are bound to be improvements that could be applied, and I
>> feel that is where the SOB could have put their efforts, and not
>> towards presenting yet another way of continuing the development
>> processes that resulted in our current situation in the first place.
>> In my opinion this fundamentally comes from the attitude of  'do the
>> simplest thing that could possibly work', and not do 'the best thing
>> in the best possible way'.
>>
>> And congratulations too to Igor for apparently taking the time to
>> understand what Keith is talking about, as shown by Igor's +100
>> comment below.
>>
>> I am very disappointed in the current extremely short-sighted view and
>> direction that is being taken by the SOB.
>>
>> I am also extremely disappointed in the way the SOB has been treating
>> the people involved ie Keith and Matthew mainly. Might I suggest
>> significant improvement in the area of people skills as a high
>> priority going forward.
>>
>> Thank you Keith.
>>
>> Ken G. Brown
>
>Ken,
>
>I appreciate you providing your point of view but I have to ask you how
>you have actively participated in the development of 3.11.

Lets be clear right at the start here, this is not about my contributions or lack thereof.
However, I've worked with Keith's Installer and helped test his new developments along the way.
I believe I know enough about software development to understand the pitfalls.
I follow the Squeak lists and believe I know something about the history and problems.
I say what I say after a lot thought in the hopes that my comments may help in some way to improve Squeak going forward.

>  I ask this
>not because I don't know the answer or don't remember (which is not to
>say that I do) or because I'm trying to single you out but because I'm
>trying to understand the disconnect that seems to be going on.

>You have to understand that when the SOB discussed this there was
>absolutely no question among the seven of us that the current state of
>the development of Squeak was untenable.

You could have chosen to help bring the board approved 3.11 proposal forward more quickly.

From:
Squeak311Proposal that the board apparently approved:
http://installer.pbworks.com/Squeak311Proposal
---
Squeak 3.11 Deliverable
 
Since the primary goal of 3.11 is the proving of the process. The base image itself will have no significant new features.
---

>We have frankly been inundated
>with complaints on one hand and near silence from contributors.  To see
>what I mean take a glance at
>
> http://bugs.squeak.org/view_all_bug_page.php
>
>If it is not already, be sure to set the project (upper right) to
>'Squeak').  Note that the 50 most recent issues (any change at all will
>pop an issue to the top of this list, except of course if the issue is
>closed which will remove it from the default view) cover a time period
>of nearly 3 months.  Dig deeper and look at the changes in that time
>period and the number of people participating and you find that very
>little is going on on this side of things.  And yet this is the only way
>to submit a change under Keith's proposal.

I'm not sure that comment is correct, at least not in my understanding.
Anyway, Keith's work would certainly benefit from further community contributions, it is obviously at an early stage.

> Of course you could also be
>directly working on Installer/Bob/MC but as far as I can tell the
>community involved there is similarly small.
>
>Can I take it that your preference now would be for us to completely
>retract the changes proposed by Andreas and go back to the way things
>were say 10 days ago?

That might be a very good and very positive step forward indeed.
In my opinion that would begin the community healing process and start to restore some confidence, in my mind at least, in the way the SOB works.
Start over on the right foot, involving discussions with the release team and come up with a more preferable way forward.
So far in this case, things have been far too dictatorial for my liking.

Ken G. Brown


>Ken
>-------------- next part --------------

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

keith1y
In reply to this post by Ken G. Brown

> I would like to present my sincere congratulations to Keith for continuing to talk sense against all odds, in presenting the Squeak community with such a well thought out way forward along with the mostly working code to implement the process.
>  
Why thank you Ken G Brown,
>  
in answer to SOB Ken

Ken G. Brown has followed our progress as a casual but interested
observer. He did take the time to understand the image build process and
to apply the scripts as instructed in order to build 3.11 prototype
images. He experienced varying degrees of success along the way and
provided valuable feedback. AFAIK Ken essentially managed to prove to
himself that you could get a new image out of the process as promised
and he did succeed on at least one occasion. We have been doing this in
different forms since 3.9.1 so its not that we don't know it works, its
about deciding which bits are done by bob (cleanUp, bumping the release
number, testing  etc) and which bits are done by the release generation
tasks.

As far as I know the list of fixes that were applied were hard coded at
the time. Work in the subsequent months, included the addition of the
extra statuses to mantis and the automation of that step, so that you
did not have to manually write the code to apply the fixes. The question
then was whether to generate code (so that it could be under scm) from
the mantis list or whether to just apply them. I also have all of the
contents of mantis exported into MC packages so that it can be scm'ed.

Ken was also the only person who responded to the announcement that Bob
was available on a public server via VNC, such that he logged in to take
a look.

Ken basically knows that all the bits are there, and has seen all/most
of the bits work individually. He, like most of us haven't seen the
whole thing deliver a 3.11 image from end to end.
> Sure, there are bound to be improvements that could be applied, and I feel that is where the SOB could have put their efforts,
Agreed,

Having just had a commercial project go belly up, having not been paid
for two months, and since Randal had said that 3.11 was not as important
as 4.0, I spent the entire month of June watching TV and doing other
things in a fairly demoralised state.

If the board had spoken to me at all in the month of June,  even once,
they didn't even have to be nice, I could easily have added the 3/4
lines of code to bob, to essentially prove the viability of, if not
finish the project. I sincerely believe that even the slightest warning
of what was coming would have made all the difference, we were that close.

As some of you know, the day before the board meeting, I had regained my
motivation to the extent that I had started documenting things with
screencasts, and I was enjoying myself again, we were on the home
straight, I just needed someone to tell about it, and through the
screencasts I had found my medium and my audience.

The line to add to bob would have been...

ReleaseAfterSqueak310 taskMakeTestCandidate run.

followed by a bit (?) of debugging...

and

ReleaseAfterSqueak310-taskApplyFixes

Installer mantis select: [ :ea | ea status = 'Testing' ifTrue: [ ea
ensureFix ] ].

(except that the code generation method would probably have been preferable)
> I am also extremely disappointed in the way the SOB has been treating the people involved ie Keith and Matthew mainly. Might I suggest significant improvement in the area of people skills as a high priority going forward.
>
> Thank you Keith.
>  
no thank you

Ken Causey wrote:

> little is going on on this side of things.  And yet this is the only way
> to submit a change under Keith's proposal.
Ken Brown wrote:
> 'm not sure that comment is correct, at least not in my understanding.
> Anyway, Keith's work would certainly benefit from further community contributions, it is obviously at an early stage.
Ken Brown is essentially correct. However the build task for 3.11 was already specified, and this build task had already selected what packages were to be loaded and that the only other contributions to be added were from mantis when the status of a fix is set to "Resolved in 3.11".

The most important part of 3.11 was to re-organise the image into smaller parts, split up System, and reorganise Test packages ao that they could be farmed out for refactoring and improvement as projects to be carried out offline and integrated in 3.12 or 3.13 etc.

There is no place in the build script for the next release to include work that has not been completed yet. If you want to make a contribution, then you finish your contribution first. The release consists of finished contributions, not places/trunks to start hacking. After all we want the next release to work dont we? If you have a small contribution that you have finished, then mantis is currently the best and only place to put it since your contribution was not roadmapped in the 3.11 plan, and that way you know it will be at least tested (if not included) automatically. There is nothing to stop you requesting that your contribution be roadmapped into the 3.12 plan but obviously we are not quite there yet.

The plan is to release often, so not having your contribution in 3.11 should not be a big deal since the build script for 3.12 alpha would be finalised within a week of releasing 3.11

Ken Causey wrote:

>Can I take it that your preference now would be for us to completely
>retract the changes proposed by Andreas and go back to the way things
>were say 10 days ago?


Ken Brown replied:

> That might be a very good and very positive step forward indeed.
> In my opinion that would begin the community healing process and start to restore some confidence, in my mind at least, in the way the SOB works.
> Start over on the right foot, involving discussions with the release team and come up with a more preferable way forward.
> So far in this case, things have been far too dictatorial for my liking.
Before anything like this takes place, the board should have a good look at its articles and terms of engagement.

My assumption was that the board, being a primarily a political body should behave like any counsel or governing body. i.e. Members of a town council or parliament have to declare their interests and if a member of the council was to award a building contract to their own company this would be against the rules.

In the context of squeak SOB, members of the board are supposed to liaise and provide encouragement, advice leadership and direction. If a person or group volunteers to do a job, then the board is able to endorse that person or not. In my opinion the board is primarily there to give the thumbs up to proposals, and give them that little bit of extra credibility and support.

Edgar was never fired from the release team as he states, he simply failed to get the thumbs up for his 3.11 proposal, since there were other options on the table. Edgar was invited to contribute his knowledge but declined. I have looked at harvesting his knowledge the hard way.  If my proposal was to be voted down and out by the board then Edgars should be given equal opportunity to compete against Andreas', however Edgar isn't on the board either.

Board members therefore should abide by the same rules that every other member of the community abides by. If they want to make a contribution to the community they should also have to submit a proposal to the board after public review and discussion, after which the board may vote and give it the thumbs up. The board can then ensure that it doesn't give the thumbs up in conflicting directions.

It is not acceptable for a board member to use the fact that they have the privilege of the position on the board, and they are present at the meeting, while other interested parties are excluded, to submit a proposal, have it voted on, and carry it out in one sitting. The board exists to represent the community, not themselves or their own agendas.

Currently following private discussions it appears that 3 members of the board believe that being on the board gives them the remit to instruct the community. Andreas says he was elected to kick butt in the release arena, and so he sincerely believes that all of his actions, emails etc were entirely justified.

I disagree, he was elected to liaise, oversee and offer leadership advice to the release team who were perceived as flagging a bit. Anyone who knows their bible will know that those who wish to be leaders must be servants first. Therefore in his capacity as a board member his discussions about the next release should at least have been limited to the release team list, and offering to serve and motivate the release team, not instruct them.

I was invited to run for the board myself, and I decided not to, due to the fact that I was already committed elsewhere, and I considered that the board was officially supposed to be relatively non-involved in technical issues. Basically I don't like politics, or endless discussions about relicencing. If I had run and been elected (a big if) then I would have been able to represent myself at the meeting.

I do not think that members of the release team should even be on the board, I would even question whether craig should be on the board since he has a vested interest in seeing spoon adopted in the future. (Craig nothing personal you understand). Craig promised spoon would be ready this time last year, I havent seen the board give him a hard time for not delivering anything. If haven't seen a message on the spoon list for a very long time indeed.

I personally think that someone with the experience of Andreas might be better put to use kicking spoon into touch.

I do think that the leaders or representatives of teams should be invited to board meetings every other meeting or so.

best regards

Keith















Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: [Release] The role of Bob, Installer & Co.

Milan Zimmermann-2
In reply to this post by Ken G. Brown
On July 6, 2009, Ken G. Brown wrote:

> See comments interspersed below.
>
> At 4:25 PM -0600 7/6/09, Ken G. Brown apparently wrote:
> >On Mon, 2009-07-06 at 15:36 -0600, Ken G. Brown wrote:
> >> I would like to present my sincere congratulations to Keith for
> >> continuing to talk sense against all odds, in presenting the Squeak
> >> community with such a well thought out way forward along with the
> >> mostly working code to implement the process.
> >>
> >> Sure, there are bound to be improvements that could be applied, and I
> >> feel that is where the SOB could have put their efforts, and not
> >> towards presenting yet another way of continuing the development
> >> processes that resulted in our current situation in the first place.
> >> In my opinion this fundamentally comes from the attitude of  'do the
> >> simplest thing that could possibly work', and not do 'the best thing
> >> in the best possible way'.
> >>
> >> And congratulations too to Igor for apparently taking the time to
> >> understand what Keith is talking about, as shown by Igor's +100
> >> comment below.
> >>
> >> I am very disappointed in the current extremely short-sighted view and
> >> direction that is being taken by the SOB.
> >>
> >> I am also extremely disappointed in the way the SOB has been treating
> >> the people involved ie Keith and Matthew mainly. Might I suggest
> >> significant improvement in the area of people skills as a high
> >> priority going forward.
> >>
> >> Thank you Keith.
> >>
> >> Ken G. Brown
> >
> >Ken,
> >
> >I appreciate you providing your point of view but I have to ask you how
> >you have actively participated in the development of 3.11.
>
> Lets be clear right at the start here, this is not about my contributions
> or lack thereof. However, I've worked with Keith's Installer and helped
> test his new developments along the way. I believe I know enough about
> software development to understand the pitfalls. I follow the Squeak lists
> and believe I know something about the history and problems. I say what I
> say after a lot thought in the hopes that my comments may help in some way
> to improve Squeak going forward.
>
> >  I ask this
> >not because I don't know the answer or don't remember (which is not to
> >say that I do) or because I'm trying to single you out but because I'm
> >trying to understand the disconnect that seems to be going on.
> >
> >You have to understand that when the SOB discussed this there was
> >absolutely no question among the seven of us that the current state of
> >the development of Squeak was untenable.
>
> You could have chosen to help bring the board approved 3.11 proposal
> forward more quickly.
>
> From:
> Squeak311Proposal that the board apparently approved:
> http://installer.pbworks.com/Squeak311Proposal
> ---
> Squeak 3.11 Deliverable
>
> Since the primary goal of 3.11 is the proving of the process. The base
> image itself will have no significant new features. ---
>
> >We have frankly been inundated
> >with complaints on one hand and near silence from contributors.  To see
> >what I mean take a glance at
> >
> > http://bugs.squeak.org/view_all_bug_page.php
> >
> >If it is not already, be sure to set the project (upper right) to
> >'Squeak').  Note that the 50 most recent issues (any change at all will
> >pop an issue to the top of this list, except of course if the issue is
> >closed which will remove it from the default view) cover a time period
> >of nearly 3 months.  Dig deeper and look at the changes in that time
> >period and the number of people participating and you find that very
> >little is going on on this side of things.  And yet this is the only way
> >to submit a change under Keith's proposal.
>
> I'm not sure that comment is correct, at least not in my understanding.
> Anyway, Keith's work would certainly benefit from further community
> contributions, it is obviously at an early stage.
>
> > Of course you could also be
> >directly working on Installer/Bob/MC but as far as I can tell the
> >community involved there is similarly small.
> >
> >Can I take it that your preference now would be for us to completely
> >retract the changes proposed by Andreas and go back to the way things
> >were say 10 days ago?
>
> That might be a very good and very positive step forward indeed.
> In my opinion that would begin the community healing process and start to
> restore some confidence, in my mind at least, in the way the SOB works.
> Start over on the right foot, involving discussions with the release team
> and come up with a more preferable way forward. So far in this case, things
> have been far too dictatorial for my liking.

Well, other's opinion may be different - I see a lot of discussion on this
topic here :) . From my perspective,  a majority elected the board, I expect
the board top make decisions, without asking the community to effectively vote
on every step. The board made a decision, and I hope they will move forward
rather than turn back...

Milan

>
> Ken G. Brown
>
> >Ken
> >-------------- next part --------------



12