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.

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