Bert Freudenberg wrote:
>
> On 06.07.2009, at 10:07, Nicolas Cellier wrote:
>
>> 2009/7/6 Ian Trudel <ian.trudel at gmail.com>:
>>>
>>> Besides, you're also missing the trick when it comes to contribution.
>>> On one side, there is quick and simple community development process,
>>> based on MC repositories, and on the other side, some matis+installer
>>> mantis+...+whatever. While the later might better fit to the release
>>> process, it is not the case when it comes to contributions.
>>>
>>
>>
>> That raises the question: where will we find a database for tracing
>> changes and providing some rationale?
>> Mantis might be unefficient, but discussions in a mailing list does
>> not cover much of mantis classification features.
>> Can it be the work of the release team to classify and document the
>> work from other guys? I bet they would soon be flooded.
>> It's also important to trace why a change has not been accepted. A
>> mailing list is too much a short memory and some subjects might come
>> back recursively.
>>
>> Andreas' proposition is certainly worth a try, but I don't see yet how
>> these questions will be addressed.
>>
>> Nicolas
>
>
> Good questions.
>
> For keeping up-to-date on what's happening to the trunk the RSS feed
> is quite useful:
>
> http://source.squeak.org/trunk/feed.rss
>
> - Bert -
Take an example

- pick a goal of image minimisation.

Andreas' way of doing it is to announce "minimisation" and let loose the
team of squeak well wishers to target something to be refactored out.
Methods wil be deleted and a new image will be released, albeit as a set
of updated trunk packages.

Those in other forks of squeak will be left with a process of forensic
coding to work out exactly what was removed, why and how.

My way of doing it is to pick a package or subsystem that needs to be
unloaded, and to move all of those methods into a new package, save the
package in a public place.

Now, any fork of squeak can load that package, (re-organising the
methods in the local fork), and then unload the package to perform the
removal. Give or take the occasional fix needed to make this process
work smoothly it does work.

For an example of a package that has been targetted for removal this
way, I took Edgars script in SqueakLight and used it to remove Nebraska
in this manner. I also factored Object-Tracer.

- pick a goal of image reorganisation

Andreas way of doing things is to again let loose the team on the
repository... Mine is to publish the task for re-organisation and allow
the team to refine it until they are happy with it.

e.g.
            "reorganize Kernel-Object"
            self category: 'MorphicExtras-SqueakPage'     classes:
#ObjectOut.
            self category: 'Kernel-Tracer'                 classes:
#(ObjectTracer ObjectViewer).             
            self category: 'Kernel-Model'                 classes:
#(Model DependantsArray MessageSend WeakMessageSend).
            self category: 'Kernel-Model-Tests'        classes:
#(DependentsArrayTest WeakMessageSendTest).

Keith