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

Ken G. Brown kbrown at mac.com
Mon Jul 6 21:36:24 UTC 2009


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, squeak-dev-request at lists.squeakfoundation.org apparently wrote:
>Date: Mon, 6 Jul 2009 21:34:11 +0300
>From: Igor Stasenko <siguctua at gmail.com>
>Subject: Re: [squeak-dev] Re: [Release] The role of Bob, Installer &
>	Co.
>To: The general-purpose Squeak developers list
>	<squeak-dev at lists.squeakfoundation.org>
>Message-ID:
>	<4a5f5f320907061134t2e781b68jf1c51d9d96c908fb at mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>2009/7/6 Keith Hodges <keith_hodges at yahoo.co.uk>:
>> Randal L. Schwartz wrote:
>>>>>>>> "Colin" == Colin Putney <cputney at wiresong.ca> 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.




More information about the Squeak-dev mailing list