Community-Supported

> That doesn't solve this problem. The loader script on SqueakMap uses an
> unspecified version of ConfigurationOfOmniBrowser. This shouldn't really be
> a problem, but the version where I fixed the Squeak (and some Pharo) part of
> it was simply ignored by others (Pharo devs). So loading the newest version
> of ConfigurationOfOmniBrowser via Installer won't work for Squeak. Other

One of the concerns we've had about legacy packages relates to when
the primary maintainers of those packages have departed the community.
 For this, there seemed to be consensus that it would be "ok" to add
additional releases that were up-to-date for the most current versions
of Squeak - leaving the original authors legacy work (for old Squeak
versions) intact.

I think we should consider expanding this to include projects for
which we can't get action.  The goal is to provide working software
packages for modern Squeaks - so what's the difference between someone
who has "departed" vs. someone who does not have time / inclination /
whatever to assist with keeping their package up to date?

I sent private e-mails months ago to several folks who are not
departed regarding projects which are in Extending the System
workspace about pasting them into the SM Catalog scripts.  But when
those e-mails are ignored, Squeak suffers for no good reason.  I'm
trying to do the polite thing by letting the owner take responsibility
but, that failing, maybe we should have a warning-protocol which would
eventually allow us to take matters into our own hands.  To reiterate,
the CSP security of SqueakMap only allows _adding_ of new CSP releases
(which can then be udpated in case of bugs, etc) - not updating the
authors original releases.

What do you think?

On 6/3/11, Chris Muller <[hidden email]> wrote:
>> That doesn't solve this problem. The loader script on SqueakMap uses an
>> unspecified version of ConfigurationOfOmniBrowser. This shouldn't really
>> be
>> a problem, but the version where I fixed the Squeak (and some Pharo) part
>> of
>> it was simply ignored by others (Pharo devs). So loading the newest
>> version
>> of ConfigurationOfOmniBrowser via Installer won't work for Squeak. Other
>
....
> I sent private e-mails months ago to several folks who are not
> departed regarding projects which are in Extending the System
> workspace about pasting them into the SM Catalog scripts.

Chris

Thank's for bringing up this topic again as a new thread.

As a help to make this discussion easier,
let me bring a specific example, the code snippet in "Extending the
System" for loading Seaside loads a particular version of OmniBrowser.
Currently it has a problem which it didn't have some time ago.

"Seaside 3.0 http://www.seaside.st"
(Installer ss project: 'MetacelloRepository') install:
'ConfigurationOfSeaside30'.
(Smalltalk at: #ConfigurationOfSeaside30) load.
(Smalltalk at: #WAPharoServerAdaptorBrowser) open.

But the load script on SqueakMap shows the same problem. This is no
wonder as the script there is exactly the same as in the "Extending
the system" workspace (SqueakMap entry for Seaside/Squeak4.2)

http://map.squeak.org/package/b135c62f-80b5-4a2f-80d4-7be8389ed54e/autoversion/27

"Seaside 3.0 http://www.seaside.st"
(Installer ss project: 'MetacelloRepository') install:
'ConfigurationOfSeaside30'.
(Smalltalk at: #ConfigurationOfSeaside30) load.
(Smalltalk at: #WAPharoServerAdaptorBrowser) open.

More on this in the thread
Testing Seaside in Squeak4.3alpha
http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-June/160293.html
(Dale H.'s post about extending Metacello)

So it is not so much a question whether load scripts of
"Community-Supported" applications reside on SqueakMap or in the
"Extending the system" workspace but rather maintaining them in a
workable state.

I perceive the "Extending the system" as showcase for "prominent",
"primary" applications.
There are only a few code snippets they of course should as well be on
SqueakMap. But please with properly tagged entries.

So "Extending the system" servers as a constant reminder to check if
the main "community supported" applications still work.

I assume most of the 773 packages on SqueakMap do not load properly
anymore. Which is not a big problem as people will make them work
again if they really need it. As we are now doing with Seaside
3.0..... :-)

I remember that we discussed about a list of "Community supported" packages in

Keep on the good work with getting SqueakMap into focus again. But
please note that this is not done by getting rid of the "Extending the
system" workspace but rather by maintaing the load scripts there (with
a copy of them SqueakMap). We do not have a proper mechanism yet
(technically or workflow ) to keep the SqueakMap entries current. Of
course suggestions and helps on this are welcome.

--Hannes


Note 1:
BTW We had a discussion on this a year ago for example under the
subject 'About configurations'

And there I found remarkable note by Andreas Raab; rhe reason for the
existence of the "Extending the system" workspace

http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151875.html

>The main reason why I don't think of it as SM is that SM
>wants to be "all packages ever created for Squeak" but what we need is
>"all packages that we've actually tested to work in this image"

It contains the "Community supported" packages, i.e. the ones which
should work with the current image at hand. And in case they don't we
have to make the work. If the load script for these packages are in
addition on SqueakMap, then fine.



Note: 2
BTW The main entry for Seaside on SqueakMap does not show that Seaside
is as well in the Squeak4.2 category.

http://map.squeak.org/package/b135c62f-80b5-4a2f-80d4-7be8389ed54e

Maybe this is the reason that the Seaside entry only shows up in
parenthesis in the SqueakMap loader?

Hi Hannes,

> Thank's for bringing up this topic again as a new thread.
>
> As a help to make this discussion easier,
> let me bring a specific example, the code snippet in "Extending the
> System" for loading Seaside loads a particular version of OmniBrowser.
> Currently it has a problem which it didn't have some time ago.

I just tested loading Seaside from SqueakMap into a stock Squeak 4.2
image.  It worked.

Scripts which load fixed configurations (e.g., with hard-coded version
#'s) are tagged in SqueakMap as working with a particular legacy
version of Squeak.

By "fixed" I mean, with hard-coded version numbers of the individual
packages.  By "legacy" I mean a past-release of Squeak that will
undergo no more updates.

These are the circumstances under which a library of software with
longevity can be established.  By "longevity" I mean, it represents a
combination of software components (legacy image + hard-coded version
#'s) that can be expected to work for a long time (theoretically,
forever).

I don't think it is reasonable to have this expectation for a moving
target - e.g., Squeak 4.3 alpha.  Once 4.3 is released and becomes
"legacy", then yes, we can.  But not until then.

Therefore, I prefer to associate the "head" release of various
packages with the latest alpha release of Squeak - and which may or
may not work with prior versions of Squeak.

Since the alpha release of Squeak is the one we are actively working
on, and the head release of packages are being actively worked on, we
should occasionally expect loading problems.

> So "Extending the system" servers as a constant reminder to check if
> the main "community supported" applications still work.

Each SM package (Community-supported or  not) is tagged with the
version of Squeak it is known to work with.  As new versions of Squeak
come out, new version tags are added to SqueakMap, of which there are
no members.  I see the resulting blank list as the reminder of what
hasn't yet been tested on the newest Squeak version.

> I assume most of the 773 packages on SqueakMap do not load properly
> anymore.

They (should) load into the version of Squeak they are tagged to load
into.  You need to leave the filter on, and just look at the ones that
are designated to load into the version of the image you are running..

> Keep on the good work with getting SqueakMap into focus again. But
> please note that this is not done by getting rid of the "Extending the
> system" workspace but rather by maintaing the load scripts there (with
> a copy of them SqueakMap).  We do not have a proper mechanism yet
> (technically or workflow ) to keep the SqueakMap entries current. Of
> course suggestions and helps on this are welcome.

Extending the System workspace is totally redundant with SqueakMap.
We DO have a technical and workflow solutions to keeping SM entries
current - I'm not sure what you mean by saying we don't..

 - Chris

Again, it _is_ just the tested packages exactly what we have on SqueakMap.

Hannes, please open a 4.2 image, and open up the SM catalog.  You
don't see 774 entries like you said before, you see exactly 22.  These
are the ones that have been tested to work in 4.2.

These will not "decay" because, the only way for them to carry forward
with the 4.3 entry is for someone to do the work of tagging it with
4.3 - which would only be done after they've tested it to load and
work under 4.3 legacy release.

Until then, the Catalog list will be BLANK in the 4.3 image.  Does
that make sense?

> It contains the "Community supported" packages, i.e. the ones which
> should work with the current image at hand.

NO, not the "current image at hand".  Only the image they are
_designated_ to work with.

> Note: 2
> BTW The main entry for Seaside on SqueakMap does not show that Seaside
> is as well in the Squeak4.2 category.

Ok, but don't go by the main entry, go by the individual version
entries - which is how the SM list is formulated in the image.  What
happened is, SM allows generic category selection, and people should
not select Squeak version type categories for the main entry - just
the category of software it is for (web, database, etc.).

> Maybe this is the reason that the Seaside entry only shows up in
> parenthesis in the SqueakMap loader?

Parenthesis means it has not been marked as "published" - which means
it my still change in the future.  Packages that are marked as
published are supposed to never change again.