I eagerly read all the discussions and offer my humble contribution (posting
to Pharo too, because I think the benefit is cross-platform):

I'm overjoyed that we are digging in and making packages easily loadable (or
clear that they are not).  I don't know what I'll do with all the hours I
currently spend fishing for working versions ;-)

Overall the goals seem to be (put best in a post from Mariano Peck):
* have a specific catalog of working and tested projects for each platform
(Pharo 1.0, Pharo 1.1, Squeak 4.0, Squeak 4.1...)
* Be able to have a hudson server running and testing such configurations. 
* Unified way to load a project. 
* (I added this one) have the least amount of effort for the developer

The Pharo and Squeak versions both sound intriguing.  I suggest one addition
that would magnify all of the above, and eliminate the accidental complexity
that versioning is adding to the mix:

***Extend Metacello specs to account for platform version (e.g. Pharo 1.0
vs. 1.1)***

In effect, since we are distilling the platforms down to the pure good stuff
- each version is a whole different platform; from a developer's
perspective, it's the same process porting to different forks and porting to
new versions of the same fork - either way, incompatible interfaces.

A hypothetical developer perspective:
	- Porting from Squeak to Pharo: I'm a developer with a project that works
on Squeak 4.0.  Now, I decide to port it to Pharo 1.0.  So I crank up a new
image and... wait, how do I load it?  I don't have a ConfigOf.  So I either
alter the Config #squeak to #squeakCommon, or load manually.  Now, it
doesn't load because there are classes that don't exist in Pharo, so one by
one, I move the platform-specific code into Platform.squeak and
Platform.pharo.
	- Pharo 1.0 to Pharo 1.1: Now, Pharo 1.1 is released, with even fewer
classes - tight core, yay!  So I go through the same process, but now I have
*three platforms* - Pharo 1.0, 1.1, and Squeak 4.0.

User perspective: simple - I want to have *one* place to go where I know
that all the packages there will work in my image, and cut out all the junk. 
And, if I'm feeling adventurous, I'd like *one* place to see what else is
out there, but very clear that it's not up to community standards - for
inspiration, to port to my platform, or to steal code :)

Once you have Metacello handling the versions
* the developers go from fork*version configs to one config
* the version problem is handled
* all other features of the current plans are preserved

This is what I envision at the intersection of what's been proposed and
Metacello versioning:
* Configs are either:
	- in one central location; it won't matter because we went from
projects*forks*versions Configs to just 1*projects.
	- or, kept with the projects they reference e.g. pick squeaksource.com, and
every project repository keeps its own ConfigurationOf (might diminish the
community involvement if read-only repos)
	>Andreas
(http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
	>Good things about it are that 
	>it's community maintained. Everyone can update everyone else's 
	>contributions and although that's not generally done, it offers a 
	>community approach to making sure things work.
* Each platform (fork + version combo) (via hudson server?  I don't know
much about them) tries to load each Config from the central repository.  If
it meets the community standards (no conflicts, tests, etc.), either the
Config is copied to that platform/fork's list of compatible Configs, or a
reference is added.
* If it doesn't load, another list could be kept with the result of the
attempt to load, so anyone who wants to use or port it has a heads up on the
status.

So:
* we don't need a separate Config for fork*version platforms.   Right now,
it seems the implementation and behavior are collapsed - we don't care where
the actual Configs are (at least in the Pharo plan), as long as we know
which ones work.  Which resolves Andreas's concern with a single repository:
	> Andreas
(http://forum.world.st/Community-Supported-Packages-td2217473.html#a2217473):
	> Also, I don't think that a single repository is a feasible option in the
long 
	> term - it seems to me that supporting the cross-product of image and 
	> package versions is going to be problematic before too long. And of 
	> course browsing repositories with several dozen of packages to find what 
	> you need isn't exactly fun either. 
and eliminated manual fiddling with the Config file:
	> Pharo proposal @
http://groups.google.com/group/metacello/browse_thread/thread/42c088d58acfb363
	> [developers will copy configs that work in Pharo x.y to]
PharoxyMetacelloRepository, then add class>>load for Pharo 1.0 version. 
* there is still one place to install for a user's platform
* you really do get "a standard way to load the packages on such repository:
just send the message load" because the spec already knows whether it will
work on that platform
* you still get a Pharo [and Squeak] release with the correct repository as
default (already added in Monticello Browser) - this is your list you copied
over

Thanks.
Sean
-- 
View this message in context: http://forum.world.st/Community-Supported-Packages-tp2217473p2218970.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.