[squeak-dev] Re: Re-liason proposal

Keith Hodges keith_hodges at yahoo.co.uk
Mon Jul 6 13:49:30 UTC 2009


Keith Hodges wrote:
> 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
>   
Question, has Andreas even ever loaded "Tasks"?

I am going to take 3 weeks out

Keith



More information about the Squeak-dev mailing list