Hi Squeakers!

"Doug Way" <dway at mailcan.com> wrote:
> @%#*!  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.

No problem, we are three now.

> (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.

Yes, I like that. And here is some reasoning too:

1. I really don't like Packages that have "loose classes" in other class
categories. Or to put it in another way - why would two different
packages have classes in the same class category? I mean, sure - I can
construct a case - but isn't it more confusing than helping? I vote for
a Package to simply be what PI is today - that way it still is strictly
hierarchical and simple.

2. Renaming PIs? Perhaps I didn't understand, but what is hard about
that? Just rename the class cats and the PI - done. Can't see the real
hard part there, but I have just had my morning coffee and perhaps it
hasn't kicked in yet. :)	

So... yes, yes, yes. Let's use the current PI. And Alex doesn't have to
worry - if he brings forward a cool new replacement - fine. We can
probably easily adopt it.

> 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)

As I argue above - I don't think that limitation really is that bad. It
keeps the mental model simple and neat. I can easily see what cats
belong to which package - at all times. If the names didn't match - I
would just get confused. And for what purpose?

But I agree with creating/splitting class cats and moving classes
around. Definitely. That is what we got stuck on the last time btw. :)
As in started messing around and then it stalled.
 
> > > 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.)

Yeah. Now - just to be short - the nice thing with my Namespace
implementation was that it didn't change much at all for the programmer
while still offering quite a few benefits usuallu found in "classic"
namespaces. And hey - besides a few snafus in the current implementation
- it WORKS. TODAY. :)

Now - I stop there. Will come back to that horrible subject another
time. 

> > [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.

Yes, definitely. Lots of parts will need that because lots of parts
don't have a guru available. Then we just need to chip in all together
in small nice teams.

> > > 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

regards, Göran