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@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
squeak-dev@lists.squeakfoundation.org