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.