Bijan Parsia <bparsia at email.unc.edu> wrote:
> One thing I really like about SqueakMap is that it brings things to me. No
> need to go out and find the right web page or archive: SM brings it home
> to my image. Yay!
> 
> Even better, it makes me want to pound on things, extend them, fix them,
> play with them, even write documentation. All to the good.
> 
> For example, I loaded up MinneStore and it seemed to work ok, in some
> places, and not as ok in some others. Some things were just a bit
> disobvious, though with a bit of explaining, they would be clear. Some
> things needed a UnitTest or 4. Etc.
> 
> I started doing a few of these things but then realized that I had No Good
> Place To Put Them. I could, of course, do the old go out and find the
> right web page, contact someone, send [BUG]s and [FIX]s and set up a Swiki
> page...ugh. No! I'm feeling lazy. I want *SqueakMap* to do this for me.
> SqueakMap is *magic*...it can fix *anything*.

Yes, this is of course on the MEGA todolist for SM.

> But my first impluse...to create Yet Another Package, seemed wrong. I

Yes, that would be wrong. :-)

> don't want SM cluttered up with twelve dozen tiny packages, often with
> just 5 lines of code. I like the clean glowing lines of SM goodness.
> 
> But I also want everything in SqueakMap.
> 
> Basically, if each SMCard was itself also a SMCategory (or sufficiently
> like one) with a certain set of subCategories (e.g., Tests, FIXs, BUGs,
> Enchancments, Documenation, Request/Comments/Tips) then there'd be a
> natural organization of these bits and pieces and a clear association of
> them with the "parent" package.

Hmmm.

> Seems to me to fit in with the use of SqueakMap for the Harvesting
> process...except that every package maintatiner gets to be their own
> Harvester. (E.g., there could be ways to indicate that a particular fix
> has been incorporated.)

I have been thinking along the same lines but with a different solution.
I want each package to have an "incoming" and an "update stream" for it.
The update stream is probably optional because some developers would
probably instead work using frequent releases, but the incoming could
perhaps be selected (by the maintainer when registering the package)
from these:

1. Simple email. When you select "Send change to package..." and then
select one of the installed packages in your image it would then look at
that SMCard and notice that, hey, that maintainer simply wants it in the
mail. Send it off.
2. An ftp incoming area. Same procedure but the change is instead
uploaded to an ftp area for the maintainer to pick it up from.

So, this would enable us to very easily just send improvements to a
"package" without having to know how the ChangeSorter does this - we
just select the package and shoot!

The next thing I would like to have is a general "annotation" mechanism
on SM, so that people can add small "notes" to a package like
bugreports, cheerful appreciation and advice etc.

But anyway, before these things will happen I have some MAJOR things to
do first:

1. Package releases.
2. Making the web UI irrelevant by adding API in SMSqueakMap for
registering/updating packages.
3. A few other important boring things. Like publishing the current
master web UI and add a mirroring mechanism (very easy).

> There are a couple of ways of implementing this, though it seems fairly
> straightforward, but I wanted to see what people thought first.

I am have a few objections here :-)

1. Having the cards "be" categories clearly sounds "cool" but muddles
the water a bit, doesn't it?
2. When someone loads the map you don't necessarily want to load info
about every little fix/enh to every little package out there. In this
respect I think it adds "too much" to SM.

The annotations I talked about is also a tad close to number 2 above,
but if the maintainer can clean it as he/she sees fit then it wouldn't
grow in absurdum. I see it as a little "bulleting board" associated with
the package that the maintainer has full power over - anyone can put a
note up there but the maintainer decides to let it stay, remove it etc.

And finally - the SM implementation is being considered "as we speak" to
form a little base around a new "Harvesting tool" in which similar
thoughts are hashed out right now. Read more on that on the SqF Swiki
under "Guides". I need to write down my thoughts there as well - Doug
has written his.

> Cheers,
> Bijan Parsia.

Cheers, Göran