Because we have to fix bug of packages that we do not know, control, want to fix... Because been agile to load and having a good infrastructure for validating packages is way more important than preloading XML. If we spend our time on the infrastructure (metacello publication, configuration certification, hudson reporting) then the complete ecosystem will get better and you should be able to automate several builds and pharo-dev whatever.
I'm concerned that our resources are limited and they are a lot of ugly ugly things in the system Now not everybody should work on them but then the insfrastructure is more important.
I agree that we should care about what packages are included in Pharo. But actually for newbies it's still complicated to discover and learn how to load a ConfigurationOfXXX.
So one goal of Pharo 1.3 should be to have a GUI to load additional tools / libs / frameworks in one click (I've seen there's one included, that's a good step forward, but some work is needed).
The tool is already there as torsten mentioned. Now what is missing are configurationOf published in the right squeaksource folders.
For Pharo 1.2 I'd rather leave XML in because today I expect that every programming environment used in enterprise supports XML out of the box.
why ruby, python, .... java does it without an import statement?
It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems.
Not loaded :) Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.