Feedback

goran.krampe at bluefish.se goran.krampe at bluefish.se
Fri Mar 11 07:20:29 UTC 2005


Hi guys!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> I don't have a specific proposal on what to do about SqueakMap and
> Universes, but my meta-response is: we should use whatever works for the
> goals we want to solve.  I'm hoping the goals can be sorted out on this
> list, and then the technology options can be analyzed.  All I meant
> in the previous post is that we have workable technology right now, and 
> so surely we should use it until something better comes along.

I agree. So I don't mind people using Universes - in fact, I applaud the
project and the effort. I only get nervous when I see the overlaps, so
that is what I want to solve somehow. :)

And don't get me wrong - I don't mean to be "turfing" - I mean that I
see people doing double work - both on the development side (you and me)
but mainly on the user side.

> A few thoughts.
> 
> First, we should not ignore the strategy where SqueakMap is a place to
> find stuff about the *whole* squeak community, while Universes is used
> to organize the development of sets of packages.  It would be much like
> FreshMeat versus APT in the Unix world.  Ideally, all these tools
> (including SqueakSource and SqueakPeople) would communicate with each
> other to try and reduce the clutter that developers deal with.

I agree, even though SM is a bit more than freshmeat today - it does
download, install and maintain a cache too. But those things we could
move out into a separate part, typically perhaps merged with Universes,
or something. (sound effect of mind churning)

> Also, I am not sure how compatible it is to have a server that knows
> everything, but a package-set tool which wants to allow private local
> servers.  These seem like goals which will be hard to solve with a
> single tool.  Although, it sounds like you are giving it a go, Goran. 
> If it works, then that's great!

I think it can work - but I also think that there will always be room
for a Universe approach in the whole scheme of it all. For example, if
mixins turn out to be too troublesome for SM, then perhaps we can focus
on having them on the "Universe level". Or whatever. So I agree, the
different goals do give us a slightly different set of restrictions to
work within.

> I think we should keep in mind that Universes does address a lot of our
> needs, even though it does not have room (that I can figure out) to
> include a registry for the entire Squeak project.  This reemphasizes, I
> think, the idea that maybe there should be two separate tools.

I think so too, I have "yet another plan" below. :)

> Finally, even if the individual programs are different, it could well be
> that SqueakMap becomes a project that includes two different kinds of
> tools in it.  That's a wonderful result for me.  I always have a large
> pile of interesting computer projects to work on, and thus I'm always
> happy for an excuse to set one aside or pass it on to someone else.  I
> have been pushing this universes stuff because it seemed that people
> could not grok it without having a prototype to play with.

This sounds interesting, I would love to merge it somehow with SM and
below is a draft plan for that. I would only take it over if you would
like me to (and anyone else stepping up for the task, see below).

> Avi, I agree that it makes sense to have some kind of public registry of
> universes.  I wish Debian had that, but the powers that be don't seem to
> emphasize that there are other Debian packages in the world other than
> those in the official channels.

Ok, what about this plan then:

1. We write a little announcement of our intentions to show the Squeak
community that we mean business when it comes to combining these two
tools in the best way we can see, and that I intend to make it happen
(giving you room to hand it over to me or anyone else helping me). I
think people want to hear a stated intention, whatever comes out of it.

2. We start by adapting SM so that it is Universe-aware in the ways I
have described. That would be a first step and I will read through
Universes in detail to see in what other ways we could do "first step
integration". The end goal here is:
	- You can register Universes on SM and of course "use" them with
SMLoader.
This shouldn't be far away in the future at all.

3. We ask yet again for the hundredth time :) on squeak-dev if there are
people interested in co-developing SM/Universes with me/us. Hopefully
one or two people come out of the woodwork.

4. I read through the Universes code once more and I write an article
describing how I would like to integrate it with SM while still keeping
all its main features intact. That way you (or anyone else) can scream
bloody murder if it sounds like I plan to do something dumb :).

5. If the article is met with agreement then I (together with anyone
that have stepped up) take Universes and merge it with SM so that we end
up with one or more packages working in unison.

After all our discussions and also after having seen how stuff works in
Lunar Linux (they have a single Universe one could say) I think that the
Universe model is a great way for preparing well controlled "managed"
sets of packages. But it does need an effort - but I think that effort
*could* be mustered - especially *in combination* with my mechanism for
dependencies. This last part is in fact a realization I have come to
after reading your Swiki pages - if we had my dependencies working, then
that would work as a great "enabler" for building Universes.

Or in other words - my dependencies are "general" in that they are
"context free". They try to describe the needs of a specific package
release without a context, and they also are based on lots of people
giving lots of input together. So it can be seen as a knowledge base of
dependency information.

Then, using that knowledge base it seems that building Universes could
be a much more pleasant experience. A Universe is in other words a
separate artifact - with a maintainer/co-maintainer etc. That is a very
distinct difference from my "pool of dependency information", just like
you have noted here and there when discussing policies etc. So you know
this of course.

Anyway, enough rambling - I think both our efforts should be available,
and I think integration first and merging second is one way to go. If
this sounds agreeable, and if Avi of course agrees :) - then I am
offering my time to make it happen.

> -Lex

regards, Göran



More information about the Packages mailing list