Here's my wishlist to Santa for 2013...

Lots of points and ideas taken from  http://wiki.squeak.org/squeak/6183

1) We need a *single* point of access to *ALL* the Squeak code (just like VisualWorks has the Cincom Public Repository).
2) We need to focus on Squeak, Squeak only code, not on every other Smalltalk environment (just like VW does).  VW, VAST, GNU, Dolphin, Pharo and others don't care about compatibility, why should we ?  Besides, Squeak is still "standard Smalltalk" (as compared to Pharo) enough that we shouldn't consider this as a big problem.
3) If we are interested by stuff other Smalltalk dialects have, we'll deal with it, port it and store it into our own repository!
4) All code must be managed/located/handled in a *single* place and in a single way : no more of this "47 ways and 47 places to import code" into Squeak!  Keep it simple (once again, just like Cincom Public Repository).
5) Everything that is Squeak code should be migrated, if possible (or if there is any interest) into that Squeak repository (and maintained passed the initial migration).
6) The load mechanism should take into account prerequisites AND their proper version for the version of the image you have.
7) Each and every package should have the responsibility of and should take into account the different platforms of Squeak (otherwise, we'd have to build the equivalent of the VAST configuration map).  The Smalltalk code should handle those differences between platforms, NOT the repository!
8) The Squeak repository should have the ability to handle any kind of project that includes code and materials like graphics, videos, sound files, PDF documentation, JPEG files, SQL scripts, etc.  In fact, any artifact.
9) The Squeak repository should be mirrored (no more "Squeaksource is down" please!).  A lag of 1 day maximum between the mirror and the official Squeak repository would be an acceptable maximum.
10) The Squeak repository should offer the possibility to browse code without loading it (Just like the Cincom Public Repository & StORE)
11) Loading code into the image should be as simple as possible (just like the Cincom Public Repository) : connect, load, done.
12) Packages have to be maintained and be up-to-date, as much as possible, with the current Squeak version.  In the worst case, it should be easy (or automatic and transparent?) to determine the right package version (and the right prereqs packages) for your Squeak version.
13) The repository (and its functionalities) should be so simple that even a newbie could use it with one or 2 clicks and be able to load any package into his image. (once again, just like the Cincom Public Repository).
14) There has to be a mechanism to notify package maintainers, after some period of time, that their packages are no longer working with the current Squeak version...  The goal is to have the package maintainers spend some time migrating/fixing/updating their package to the latest Squeak image so we don't end up with 9284 projects out of which only 10% are useable with the current Squeak image.
15) Ideally, all packages should come with SUnit tests.  That could allow us to automate the verification of compliance of every package with the current Squeak image.
16) The Squeak swiki should, once that repository is in place, delete all references to other "methods" (locations as well!) of getting the code for those packages and replace those pages/links with the appropriate reference and documentation pointing to the location of those packages in the new Squeak repository.  You shouldn't need to use Google to find a Squeak package anymore!  Everything "Squeak" should be at one place!
17) Revisit Squeak tools to work with and take advantage of the Squeak repository, which means better diff/merge/consolidation tools.
18) Publishing/committing code to the repository should be simple and straightforward.  Handling of differences between platforms should be handled within the image, in Smalltalk.  The simpler, the better!  Once again, platform-specific code should be handled in the image otherwise we'd have to build the equivalent of the VAST Configuration Map mechanism.  Keep it simple! (see item 7).  In the very worst case, provide a core package and different "platform specific" packages.  The user will then have the possibility to load/unload what he needs for his platform.
19) Locally cached packages should allow anyone to work "offline" and later publish (Just like VW StORE)
20) We should think about the future, which means allow for extension, easy migration and modification..  Who knows, in 1 year we might be discussing about integrating namespaces to Squeak, method overides, class extensions, etc.
21) The repository itself should be maintainable (not a closed "3 people on Earth understand how it works internally" kinda thing).  StORE saves stuff in a relational database : it's easily understood, can be queried by a gazillion tools, can be backed up, migrated, etc... Sometimes, not everything has to be dealt with Smalltalk...  ;)

 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121220/12e4574f/attachment.htm