@%#*!  I sent a reply last night, but I guess I closed my laptop before
it actually got sent.  Anyway, it was a short-ish reply, which I will
re-summarize here...

On Tue, 8 Feb 2005 16:06:23 +0200 , goran.krampe at bluefish.se said:
> [SNIP]
> > > Great! TFNR is now my prio uno too, apart from replying to all the SqF
> > > hoopla, spitting out the bi-weekly and making the new SM. :)
> > 
> > Someone else should really take on the bi-weekly report, you already
> > have enough on your plate. ;)
> 
> Yeah, but Blake is helping with the report now. So the next should be
> easier.
> Want to help you too?

Sorry, I'm not able to help right now, but it's great that you have at
least one helper.  This is something that you don't necessarily have to
be a Squeak guru to help out with.

(big snip)
> > Ok, although it may be worth pausing *briefly* to consider Stephane's
> > comments about whether we should use a real object instead of
> > PackageInfo with its string-based naming hack, so that you can e.g.
> > easily rename a package without worrying about the class category names.
> 
> Ok, counting to 1, 2, 3... time's up! Alex!!!! :) :)
> 
> > Maybe there is a simple solution using a real object which has a similar
> > API to PackageInfo and organizes packages in exactly the same way, which
> > is also reasonably backward-compatible with existing browsers.  But I
> > don't want to wait long either, we need to look at it now and make a
> > decision.
> 
> I assume this is exactly what Alex is building - but we can't wait,
> wait, wait...
> Unless this code is posted within a day or two I say we go with PI as it
> stands or I will hack it myself.

Hack your own PackageInfo replacement which doesn't rely on category
names, but is otherwise very similar?  Something simple might work.

One approach we could use is to just go ahead with PackageInfo as it is
right now, and if a suitable replacement comes up early enough in the
process (say, in the next few weeks) we could convert all of the PI's
over to the new package object.  This would let us proceed right now
without waiting.

If we do proceed with PackageInfo (Monticello) as it is, we need to
consider that we shouldn't be *too* cautious in changing our package
partitioning because of what the current Class Category organization
happens to be.  The current Class Category partitioning is a reasonable
starting point, but if we decide to merge or split packages (say,
splitting Morphic into Morphic and Etoys), then we have to be ready to
rename the class categories for the Etoys classes to Etoy-whatever, etc.
 An obvious point, I suppose, but this is the limitation of PackageInfo.

An ideal replacement should have the package name be unrelated to the
Class Category string. (which is probably what Alex is doing)

> > I think we are agreed that we do not want to tackle namespaces or
> > anything like that right now, at least.
> 
> Yes, of course. Even though I still wonder why people didn't like my
> namespace implementation. :) Seriously.

I'm sure that will come back up whenever we start discussing namespaces
again. :)  (I was unable to look at it closely enough at the time to
form a strong opinion.)

> [SNIP]
> > Great.  Getting back to finding maintainers, it might be best to assign
> > four or five maintainers to a big package like Morphic (with one lead
> > maintainer), rather than assigning individual people to smaller pieces
> > like Morphic-Windows, etc.  We will probably have more success getting
> > complete coverage that way.
> 
> Yes, definitely. I am for example hoping for Ned and Juan and possibly
> Diego for Morphic. And perhaps one or two more. I would propose Ned as
> head Steward in that group.

Yes, I could even sign on as a fourth or fifth member of the Morphic
group, if needed, since I'm familiar with some sections.  Whereas I
would not want to be the lead maintainer.  Hopefully we will have more
luck recruiting people if they know they will be part of a small team
and won't be stuck with sole responsibility.

> > My initial thought was that the single Kernel "package"/image could run
> > on its own.  But I don't have a strong opinion on that.  We can let the
> > people in charge of those areas decide.
> 
> Well, let's just choose and go for it. I happen to know a bunch of names
> that volunteered earlier for Collections - which is why I want that in a
> package of its own. :)

Sounds good.

> [SNIP]
> > Alrighty, we're getting ready to roll. :)
> 
> Honk! Honk! Viva la re-revolucion! :)

Okay, now for the next steps... :)

- Doug