Torsten Bergmann wrote:
I think the naming is more related to historic
development: my original implementation just had one tab
named "Configurations".
Esteban later added "Untrusted" since these are the ones
that are not (yet) tested in the according Pharo version.
It's a nice addition since it makes them easily accessible
as well.
However I now changed the tab names to "Core" and "Community"
in
http://code.google.com/p/pharo/issues/detail?id=7154
Reminder:
=========
It is still required that people try out the "Community"
ones and if they are working fine in Pharo 2.0 copy them to
http://ss3.gemstone.com/ss/MetaRepoForPharo20
so they appear in "Core"
So anyone (having done the necessary validation for 2.0) can copy into
the MetaRepoForPharo20 ?
I had misunderstood. I thought the distinction you wanted to make was
identifying which Configurations the Inria Pharo Team took direct
responsibility for supporting, which I thought was a reasonable
distinction and I would find useful.
If the idea was to gather all Configurations that worked in Pharo 1.4 to
make it easier to jumpstart testing them in 2.0, then I was incorrect to
suggest renaming that to "Community". I was thinking a "Community" tab
would be packages validated for 2.0 but those outside the Core Pharo Team.
Rethinking this, perhaps having a "Consortium" tab would be useful.
This would be an additional benefit for members to populate, giving a
higher profile for any of the packages they provide or the products
depend on. The side benefit for members is that wider usage of the
packages they depend on means more eyeballs and hands improving those
packages. The benefit for me as an end user would be a list of packages
that are likely used somewhere in a real customer facing product with
attendant professional level of care and maintenance by others.
Along the same lines there might be an "Association" tab for members of
the PUA to use. The benefit to me as an end-user is seeing which
packages are liked/supported by those with a higher level of commitment
to Pharo. This doesn't necessarily need the main developer to be a
member, just that a member finds it of use to themselves.
To avoid needing to manage multiple MetaRepoForXXXX on squeaksource
server side, perhaps the Configuration Browser can pull a status file
from the PC & PUA websites. On the websites members could see a list of
Configurations in the MetaRepoForPharo20 and "Like" the ones they want.
ConfigurationBrowser could continue to pull the Configurations from just
one location, and the categorization done on the basis of these status
files.
A "Backward Compatibility" tab might be useful to segregate out things
like ConfigurationOfFileDirectory, clearing identifying it as deprecated
so as not to confuse newcomers, and also provide a jumpstart for anyone
wanting to port old pre-Pharo code to Pharo.
"Consortium" might be inclusive of "Core" to avoid having too many tabs,
and also since maybe many Consortium projects might be
private/commercial and this list might remain lightly populated.
anyway, just random thoughts bubbling over,
cheers -ben
