You might notice you're actually agreeing with my first point, and it
sounds like we're only partly disagreeing on the second.

You say three things (IIUC - please correct me if I don't)
A. Packages should not be as small as a fix, but should be bigger, say,
application size or library size.
B. Fixes should go into the image.
C. Integration is a lot of work.

As to the first, this is not a problem of policy, it's a problem of
mechanism. Right now, in SM, all package are equal. Since small things
get made more often than bigger things, big stuff becomes harder to
find. Most Debian UIs hide libraries. The libraries are loaded as needed
by the applications, users don't choose specific libraries. In the same
way, if I understand you correctly, Squeak users should not have to
choose their applications from among a huge list of fixes and
enhancements. 

Fine, I agree. The solution includes using load scripts to aggregate
packages, so that people can load one load script, and get Jacaranda
working, with Connectors automatically included, and also all the
appropriate fixes. Another part of the solution is that some packages
that are "libraries" should be hidden most of the time, and possibly
also fixes and the like. That way, most users, most of the time, will
not need to pick from a huge list. 

Note that when I thought about what SMLoader should look like, I thought
explicitly that the important thing is to make it easy to start working
with at the beginning, when there we 14 packages. I consiously made
tradeoffs to that effect, at the expense of scalability. If people say
that there's a better GUI they prefer to use, that scales higher, I
would be delighted to see it replaced. I think a hierarchial view would
work pretty well, if combined with keyboard control of the hierarchy
(which is available), and a very available search function.

About fixes going into the image, I agree. But these are not *obviously*
fixes, and unless/until everybody likes them, they can live just fine in
packages. The most important functions SM fill is to make the Harvesters
free to not include in the image things that add function, and to make
makers of such things free to publish them anyway.

About integration (and testing) being alot of work, I didn't disagree
before either. Which is a good reason to spread it as much as possible
through the community, and not confine it to merely the Harvesters. As
I've said before, it also has the benefits that you can test packages
far more lazily than the image itself - it's easier to update them, and
if you have a bug, it affects less people.

So when packages have bugs or conflict, their users discover this, and
their maintainers fix it, and it's no big deal.

Daniel

Martin Wirblat <sql.mawi at t-link.de> wrote:
> 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