Sebastian wrote:

One should discuss if it might be useful and easy to implement to have a configuration browser that includes descriptions for the offered configurations.

I guess I'm knowledgable enough to answer this: a) it is useful b) if it is easy depends on where you get the description info from c) Do not dicusss, stop lamenting and help coding :) When I wrote the config browser there was no central way to find out which packages/configs are working for which Pharo version. The easiest thing that could possibly work was to create a MetaRepoForPharoXXX repo for each version XXX of Pharo and copy the working configs into it. The tool just queries the list of available file names and displays them. For the initial step this was enough and still good enough that the tool opens quick enough. If you would LOAD ALL the configs in such a meta repo BEFORE OPENING into the Pharo image to extract more informations (like descriptions or dependencies) the config browser would be unusable due to bad performance of such operations. This could be solved by caching, but so far there was no time. Additionally as it makes sense to store such descriptions with the config Stef implemented Catalog. Some ConfigurationOfYYY classes have such meta data for Catalog and the project currently produces an HTML report: https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ One must know about this. Not ideal - but a step forward to at least make it visible somehow. Several options: ================ 1. Implement a solution to load all the config in the meta repo into the image, extract the data the first time and write this info to a cache. Update the cache on request. It MUST be cached, otherwise it will burn CPU cycles. Although this cache can be shared between Pharo image with the same version I think this is not ideal. 2. Using Stefs "Catalog" project one could (beside the HTML report) provide something that is easy to parse from the tool so we can load the contents of the displayed list from the web quickly When the CI runs often it should be up to date always - but we must make sure such a job is never broken. Would be a better option - but also needs someone to do that. 3. In the long term: Implement a better online mechanism to register Pharo related stuff. Some kind of PharoStore where you can register and share Packages but also other things like tutorials, articles, video, wallpapers, ... Then the client can query for this info (maybe using Spotter) and just load. Feel free to shape/code on improving this. There is something in the pipe for 3. from my side already, but only slowly progressing maybe too much work for one person. If you want to help and know Pharo and Seaside very well then contact me offline.