On Tuesday, February 8, 2005, at 09:06 AM, goran.krampe at bluefish.se 
wrote:

> Hi Doug!
>
> No big news in this reply, but anyway.
>
> "Doug Way" <dway at mailcan.com> wrote:
> [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, not able to help myself, but it's great that you found at least 
one helper.  (Anyone else interested in helping should email Goran... 
:) )

> (snip)
>>> Great. Let's do it. We simply just add a cs that makes PIs more or 
>>> less
>>> based on the current class categories IMHO. Stuff can be moved around
>>> later. Agree?
>>
>> 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 together an improved PackageInfo?  Something simple might work.

Another option might be to just go ahead with PI as it is, and then if 
an improved packaging object comes along reasonably early in the 
process, we can just convert everything over to that at that point.

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

Probably this will get re-discussed when namespaces come back up. :)

> [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, groups of people is good.  Make it clear that we're not expecting 
anybody to do a redesign or any major rework necessarily (unless they 
really want to)...

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

True, that is one reason to consider keeping it in a separate package.

- Doug