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?

> > But really, we JUST HAVE TO DO IT this time. Damn shame we are in
> > different timezones. Can you pop over to IRC whenever you can and we can
> > see if we overlap? I am there during my work hours, hardly anything on
> > weekends these days - family takes prio.
> 
> I will try to get on IRC, but it may be tough to do from work, I have to
> figure out proxy/firewall issues.  (Is there a way to do IRC through a
> web browser? ;) )  And then evening-time here (EST) is 1am-5am Sweden
> time, ah well...

I will probably log on later tonight - in about 4 hours. When Maya is
asleep. :)


[SNIP]
> Well, this issue needs some more thought.  The Package Loader currently
> also treats changesets, .sar files etc as "packages".  But they're not
> "real" PackageInfo packages.  I'd like a list or browser tool somewhere
> which only shows the "real" packages, which can be browsed, unloaded,
> and otherwise manipulated.
> 
> I suppose one solution is to have the Package Loader show the installed
> items, including real packages and other SMpackages (changesets, etc). 
> But only have the Unload/Browse/etc capability enabled for the real
> packages, which you suggested below.

Right.

> I guess I mainly just want to see the list of all real packages when
> browsing source code in the image.  So perhaps all we need is a real
> Package Browser (sort of a different System Browser) which lists Package
> names in the upper left corner, and then the next four panes across the
> top are the same as the MC Snapshot Browser, including Extensions etc,
> and then a code pane at the bottom.  You use this tool to browse/edit
> all the code in the image (but it could also do a few extra things like
> unload packages, too).  Then we wouldn't need the Package List.  And
> this is somewhat separate from the Package Loader/Manager's
> functionality.

Yes, sounds dandy. And yes, I read Stephane's post about Alex working on
all this - but pretty-please-with-sugar-on-top - post to the list about
what you are doing Alex!! We can't just sit and wait.

[SNIP]
> Anyway, this Package Browser could be worked on in parallel with the
> initial partitioning work.

Yes, definitely. I will not wait for it. :)

[SNIP]
> Right.  I think we have to live with the fact that class initialization
> will happen on load, and it may not be reversible, but we are trusting
> the packages not to do a lot of bad/unreversible stuff during class
> initialization.

Yes. Again, I just wrote about it so that people understand the issue.
Today there is no code around to reverse these things, it needs to be
written. And it will have bugs. But sure - this is the way to go.

[SNIP]
> "Package Manager" might be alright.  Maybe think about it for a bit
> first, and how it might fit in with a Package Browser described above.

Yeah, no biggie. We can call it loader a while longer. :)

[SNIP]
> Okay, maybe get rid of it if we have both a Package Manager/Loader and
> Package Browser.

I think so.

[SNIP]
> > > > 1. TFNR. Yes. Let's finally partition the image and put people in  
> > > > charge
> > > > of each part. Yes, the parts will still be totally intertangled - but
> > > > each line of code will have a maintainer. And each logical "tool" or
> > > > "mechanism" will have a caring Squeaker. We should do this NOW.
> > > 
> > > Sounds good.  I am on board!
> > 
> > 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.

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

[SNIP]
> Right, well, I'm just talking about the very basics, I think we already
> have most of what I would consider a basic plan:
> 
> - We will use the update stream to partition and then detangle the
> image.

Right.

> - We'll assign maintainers to each package after partitioning, before
> detangling.

Right. If it doesn't end up perfectly right - they can fix it between
themselves. :)

> - We will use XXX (PackageInfo or something very similar) as the basis
> for packaging. (This one isn't decided yet.)

Right.

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

[SNIP]
> > No, we should definitely not wait anymore. I am not even sure what we
> > would be waiting for.
> 
> Well, let's hear what the other alternative is, anyway.  (For a *Brief*
> moment. :) )  But it is true that we could convert PackageInfo packages
> to something more robust later, since the eventual package
> partitioning/detangling should be roughly the same whichever one we use.

Yes. I give Alex/Stephane 24 hours to yell out and post code (I only
want a new PackageInfo/PackageOrganizer - I don't care about UIs at this
point). :) :)

Only half joking.

> > > may end up changing the class categories of a lot of classes to make  
> > > this work.  For example, "Collections-*" might have to be renamed to  
> > > "Kernel-Collections-*" if we want the Collections-* classes to be in  
> > > the Kernel package, which is where most of them would need to be.  Can  
> > > the package names be unrelated to the class category names?)
> > 
> > Well, I would favour having separate packages. Why can't collections be
> > a separate package?
> > 
> > I mean, sure - it will never be uninstallable, but it seems you would be
> > able to upgrade it to newer releases at least. Hey, that is a thought
> > worth noting...
> 
> 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. :)

[SNIP]
> Alrighty, we're getting ready to roll. :)

Honk! Honk! Viva la re-revolucion! :)

regards, Göran