Harvesting was: [Q] a couple of questions related to look enhancements

Daniel Vainsencher danielv at netvision.net.il
Mon Mar 31 01:31:34 UTC 2003


Hi Martin.
Martin Wirblat <sql.mawi at t-link.de> wrote:
> Every good basic enhancement like these should eventually go into the 
> base image. 
Axiom I - for every changeset E someone considers an ENH, there exists
someone else that considers it as more cruft. 

I agree Diego's stuff is very good looking, and might someday even end
up as an alternative default look, or part of it, but 
A. Its not quite as clear cut as you think (see above).
B. Since SM exists, there is no harm in letting ENH's mature there
before inserting them into the image, where their maintainance becomes
much heavier (since changes for it needs to be harvested). And lots of
benefits...

For example, while I view the keyboard control of hierarchial lists as
very cool, and very useful (it makes using the explorer a completely
different experience), I'm glad it's in SM now, and should get more use
before we integrate it into the image.

We need to do everything we can to make maintainance of the image go
faster, including excluding as many things as possible from being in the
image, exactly in order to make it's evolution faster.

> To have thousands of 
> people sifting through SM and searching the 100 packages they need to 
> make Squeak what it could be is a colossal waste of resources. 
That is true. If you have good ideas for how to improve the
UI/model/functionality, send them in, Goran listens very well. Ideas
amounting to "the Harvesters should do something about this" are not
very useful.

> For those who are now inclined to murmur 'loadscript': To write and 
> test this loadscript is hard work. It is essentially the same work as 
> to integrate things directly into the base. To have a complete and 
> universal base is much more valuable than to have 1000 parts which 
> have to be assembled first. 
Ooooh - now here I gladly and enthusiastically disagree - we simply have
a better solution. Point by point -
A. Writing a load script is trivial. I've sent a generic one to the list
a while ago. Using the SM API, it's a couple of lines of code. See the
code SM uses to load SMLoader, for example. That's a load script.
B. While *integrating* the load script with the released image is
exactly the same kind of work as Harvesters would need to do, it has two
major differences -
  1. Anyone can do it, and his work will be just as well as effective as
a Harvesters, since once on SM, anyone can use it.
  2. The fact that you do it doesn't force other people to accept this
package, so concensus is not required.
C. Writing a load script is a way for you to create and distribute your
own view of what the image should be like. If a lot of people come to
agree, it paves the way to making the packages better, and if
appropriate, part of the image. So in regard to your last sentence, 1000
parts aren't just an alternative to a whole, they're also the right way
to get there.

> The Squeak of the future should be made up of few big modules, and not 
> of a mess of fixes and enhancements.
If you mean it shouldn't be that every user has to assemble his fixes
and enhancements - I agree.
If you mean things should be preloaded in the image, I beg to differ.
Debian is IMO (and that of many people who've tried it), the easiest
Linux distro to use and maintain, exactly because it is made of modular
parts.

> On SqueakMap are already some packages which fall into this category.
> The harvesters do have to harvest on SqueakMap too!
Just to make this factually crystal clear - the harvesters don't harvest
from SM. Anyone is welcome to post [FIX]/[ENH] message that refer to SM
packages. If you want us to treat this seriously, use QA tags.
 
Daniel



More information about the Squeak-dev mailing list