ClassBuilder fix, SqueakMap, and releasing 3.4

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Thu Mar 6 20:40:53 UTC 2003


Hi all!

Colin Putney <cputney at whistler.com> wrote:
> On Thursday, March 6, 2003, at 09:57  AM, Brent Vukmer wrote:
> > Colin --
> >
> > I don't think that's an argument for not registering 
> > packages-that-aren't-quite-packages-yet.  Instead, it's an argument to 
> > enhance PackageLoader so that if filters the list to hide PTAQPY's by 
> > default.
> 
> Ok, so then we'd have a package in the SM database that's neither 
> installable nor visible in the list. How does that help us?

Well, *if* (obviously I am outnumbered but hey, I don't give up that
easily! :-) ) such a package-not-yet-broken-out-of-the-image (I agree
that the kernel is a bit special, but not totally impossible to break
out - for example the Compiler could be broken out in some scenarios)
would be on SM then I would like it to be visible, I mean - what is
otherwise the point? :-)

And since it has no download url it would not show up as "installable"
of course. So newbies would probably not get confused.
 
> Now, I love SqueakMap as much as the next guy. But let's not go 
> overboard here. SM is a catalog for packages that are not in the image. 

Eh, well - if that is your definition then you are already "wrong" in
one sense - there are currently packages in SM that still *are* in the
image. You know - waiting to get removed from the image. ;-)

> It provides a way to easily find and load these packages. It's *not* a 
> registry of Squeak development efforts. That's what the Swiki is for.

I agree. Not a registry of "efforts". But I do think it is a registry of
*parts of the Squeak artifact* with associated maintainers, authors,
version, description and homepages. Etc.

And I actually do think almost any part of Squeak should be able to be
registered like that.

Another example would be if Richard O'Keefe took upon himself to
maintain/steward the Collection hierarchy (just theoretically).
Obviously the Collections are hard to break out - some of them even
impossible. So does that mean it could never be registered on SM? I mean
- it is a well defined piece of Squeak, it has a description, a name, a
maintainer/steward, it could have a version, a development status, etc.
The only thing missing is a download URL.

And what about later when we start using the map for other tasks? For
example, bugs that get reported needs to be forwarded to the correct
maintainer - but how do I then report a bug in the Collection classes? I
can come up with tons of these use cases. For example, to be able to
send out a message to all core maintainers that a feature freeze is
coming up. Ok, Richard and SCG guys would miss that then because their
parts of the Squeak cake isn't registered... ;-)

IMHO any part of Squeak (and hey, even VM ports or plugins or prebuilt
images or xxx) should be possible to register on SM.
 
> A package should be registered on SqueakMap when it can be downloaded 
> and installed into the image. What's the rush? The KCP may not produce 

Hey, no rush at all - it was just a silly thing that I wanted to bring
up. :-) Really.

> a separately loadable package. It *is* the kernel we're talking about 
> after all. Or it may produce several packages, that break various bits 
> of functionality out of the kernel. We don't know yet.

I agree. I think that I still maintain the view that a part of Squeak
which has a boundary and a maintainer/steward should be registered on
SM. Just MHO. And btw, in SM1.1 there are a few new beasts that you can
register that definitely are NOT packages. 

Btw, Colin - have you done any good snowboarding in Whistler then? I
just had my yearly dose without breaking anything. :-)

> Colin
> 
> Colin Putney
> Whistler.com

regards, Göran



More information about the Squeak-dev mailing list