Hi Keith,

see also my other message.

On Sat, 04 Jul 2009 15:00:09 +0200, Edgar J. De Cleene wrote:

>
>
>
> On 7/4/09 9:30 AM, "Keith Hodges" <keith_hodges at yahoo.co.uk> wrote:
>
>> I will start again...
>>
>> My point is that any worthwhile refactoring project will probably
>> transcend the majority of packages, both in the kernel and without.
>>
>> Example 1. Replacing FileDirectory - will effect a high percentage of
>> packages in the kernel and virtually every package in SqueakMap will
>> need to be ported.
>>
>> Example 2. Namespaces - will effect a proportion of kernel packages and
>> MC tools, compiler etc.
>>
>> Example 3. Replacing _ with := is not a project that is rescricted to
>> one repository.
>>
>> Eaxmple 4. Logging
>>
>> If you have a headless image, you might want to use a logging device
>> instead of Transcript. So every place in the kernel where people have
>> put Transcript show: in order to fulfil the role of "logging" would need
>> to be replaced with a call to the logging dispatch framework. i.e.
>>
>> "Transcript show: someValue"   becomes something like "self log info
>> kernel someValue: someValue."
>>
>> ==
>>
>> So here we have 4 projects that could be undertaken to improve squeak.
>> What do they have in common...
>>
>> 1. All of these projects could be applied to any existing squeak image,
>> cobalt, croquet, gjallar, pharo, 3.7 - 3.10 etc. So the potential target
>> audience is not just 3.11 users (who only represent a minority of the
>> squeak community).
>>
>> 1. None of them would be doable using the package maintenance model that
>> you are proposing. It is not true to say that one team can work without
>> bumping into another team as you propose.
>>
>> 2. You wouldnt be able to undertake any of the above projects
>> concurrently within a single repository, without people falling over
>> each other, and or the projects becoming inextricably linked.
>>
>> 3. The knowledge capture as to how to perform each project gets confused
>> with the activities of the other projects. Therefore this knowledge is
>> not useful to anyone other than the developers of that one image. If
>> Cobalt wants to use Logging too (and they already are doing so) they
>> would have to repeat all the work from scratch they would not be able to
>> reuse any of the knowledge gained from doing it in 3.10. Why? because
>> the the process of performing the refactoring was done against a moving
>> target, and it is not possible to say... You applied this process to
>> image 3.10 and I want to apply it to my image which is derived from 3.8,
>> if I analyse the differences between 3.8 and 3.10, I should be able to
>> take your delta  (DS/CS) and apply it to my image.
>>
>> Keith
>>
>
> Keith you should think in start your own fork as Juan, Pavel, me , and
> others do.

Well, be prepared guys: the more forking, the more comparision, the more  
competition ;)

> Your way is very different as some of us think is a .image development  
> and
> the only way is having some .image which people could try , see his  
> number
> change from 7159 to higher numbers, broken things was fixed and wild  
> ideas
> show his value.
>
> My 5 centavos de peso , what worth almost 1/100 euro.
>
> Edgar
>