[squeak-dev] Object >> future
keith
keith_hodges at yahoo.co.uk
Wed Mar 10 20:07:27 UTC 2010
>
> Why do you feel that you are entitled to have me make this available
> in whichever image you've decided to use? I have not heard users of
> Cuis, Pharo, or Cobalt ask for this functionality. Why should I
> spend my limited spare time creating and maintaining loadable
> packages for these?
Because if you had thought about the problem first, in the light of
the fact that we are living in a multi-fork world, then your
innovation could have been designed to be potentially loadable in all
forks from the start, and derived images (with tool support to help
you with building and testing it in all targets) , and you could have
used 3.10.2 as one example use case of the integration of that
innovation, for others to copy.
This is what us package developers have been doing for years. If I can
do it for Rio, and Logging, you can do it for your stuff too.
The crime is that the process you are using, "trunk" causes you by
default to think and act as if you are in a one fork moving target
world, and to think in a "I will just throw this in for good measure"
manner.
The end result being that your efforts integrating it into trunk will
inevitably have to be repeated by others. However those others do not
have your knowledge and will all have to reverse engineer everything
you did and guess at all of your design decisions and the fixes you
had to add to trunk to accommodate.
This means that the net result for the community is that you, in your
attempt to provide a simple new feature just for your own pleasure,
have actually generated work for other people, and this is what i
think can be improved. What is needed is some form of knowledge
capture on the way.
I am not saying you have to package it as loadable for everyone, but
it would be helped by a process which identifies your work as a
discrete separate lump, rather than mixing it in with everything else.
If you had simply developed it for 3.10.2 rather than trunk, that
would have done the trick.
In the "grow" scheme I have 4 or 5 kernel innovations on the go. But
they are all being developed relative to the base-dev image. This
keeps things uncluttered. If these innovations interfere unduely with
one another then this is a clue that I need to improve their modularity.
It is then trivial to generate a build with all 5 innovations loaded,
even though it may not work immediately.
If one of the five innovations loads in cuis-base-dev, then the
knowledge I need to make that happen is captured in the fixes that go
into the cuis-base-dev package. When I load it into pharo, I port just
that knowledge, into the pharo-base-dev package. As the base-dev
images get more api commonality. Then when it comes to porting the
other 4 innovations, to the other forks it gets easier.
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100310/ee8fe3e4/attachment.htm
More information about the Squeak-dev
mailing list
|