Harvesting was: [Q] a couple of questions related to look
enhancements
Martin Wirblat
sql.mawi at t-link.de
Mon Mar 31 18:19:08 UTC 2003
Hi Daniel,
I knew you would enthusiastically disagree with 'murmuring of
loadscripts' :)
> A. Writing a load script is trivial.
The script itself is trivial, but as I said you need to test it,
meaning you have to run it AND test the resulting image. This is
testing a release! If you have more than one loadscript it is
something which is MORE work than testing a monolithic image release
today. Have in mind here how many bugs, problems or not quite
beautiful things are in the single image of today.
There are not only packages depending on other packages, there are
packages excluding each other, and this not only in a syntactically
detectable way ( name clashes, class and method redefinitions ) but as
I fear in many more subtle ways. E.g. programs produce data with
data structures on disk, communicate with protocols, have semantics of
their inst and class vars or have implications regarding the UI. You
will not find such incompatibilities in an automated way. Something on
top of assembled image A may not work on top of assembled image B or
may hamper something in B, even if the dependency system gives green
lights.
These two points led me to the conclusion that it is best to keep the
number of packages for the official releases as small as possible and
the packages as big as possible. Of course it is a question of
sensitiveness to find the optimal balance, but I really think that
something like Diego's font-enhancement for the pref-panel is more a
fix of something ugly - it should not be a package for loadscripts.
This leads to Debian: Most modules of Debian are full blown
applications or at least tools or libraries, they don't have minor
tweaks and fixes which you can combine together to your personal
system.
The finer the granulation of modules, the more interface vs function
there is, the bigger is the chance of problems. Debians module
granulation is huge compared to the small SM-packages which I think
about.
> Just to make this factually crystal clear - the harvesters don't
> harvest from SM.
Exactly because not everyone puts his code on the right avenue this is
a problem.
regards
Martin
More information about the Squeak-dev
mailing list
|