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