Feedback

[goran.krampe at bluefish.se]

Hi guys!

Evidently it is dangerous not being online for a weekend. :) Anyway, I
have read all posts to this list and would like to make some swift
comments first:

1. If I read you right Avi, you suggest us sticking with PI as it stands
today. I tend to agree, we will learn a lot through this project and we
can always migrate to something like Alexandre's recent work afterwards.
PI is being depended upon quite a lot right now so sticking to it,
disregarding its warts, is the way to go at this time - we all know how
it works and the tools work with it. Also, Ned has recently posted a
"power pack" for PI including some split-changesets-based-on-PIs that I
and he wrote independently. I strongly urge us to perhaps make that
stuff an official package in Basic and get it in. :) Or just merge it
into whatever places it affects (ChangeSorters etc, the PackageInfo
package). Just as long as we "gear up" properly for our quest. :)

2. Your initial post didn't clearly express the idea that we can indeed
"stake out" the image without having to actually "break out" parts of
it. I think that piece of the puzzle is important. The TFNR idea was
precisely that, meaning that it is better to have a tangled mess that is
staked out, than to have a tangled mess. :)

So I would like for you to clarify your view on that. In other words - I
would like for us to make a 100% stake out *first* (it can be made quite
quick if we don't get too granular - let the PIs divide themselves later
if their Stewards feel the need), and then *after* that start breaking
out stuff. And sure, we may end up with a few "largish" PIs and perhaps
even a "what is left in the bucket"-PI but so be it, then we at least
have a *fully covered* image AND using the existing field in SM we can
map each such PI to an SM package and thus we know *who* stewards it and
what emails they have etc. And just by accident we can then (given Ned's
power pack) use the changeset splitting mechanism to easily feed
multi-package-covering-changesets to the maintainers.

Ok, I reread your post and perhaps you *do* indeed mean this - sorry if
I misunderstood. :)

3. I intend to focus on SM now, it seems that we have managed to get
ourselves organized pretty good and we do have a plan for the next few
months in place. So *my* main Team is *this* team and my main job in
this team is SM. :)


And regarding the future of SM:

1. Lex mentions a few needs currently not being addressed by SM. One is
the ability to have "private" repos - or in other words to decentralize
SM into multiple connected servers in some way. This has been in my plan
for a long time but I have postponed it because I didn't want to limit
the model because of it. I am all ears for making this happen, but not
before dependencies or a few other good things. Then, when the model
looks somewhat "complete" we can again try to fogure out how we
distribute it. :) And also, Avi has a good point in that SqueakSource
etc fills a "developer space" that SM doesn't - so the need is less
today than it was before SqueakSource/Monticello I guess.

2. The ability to be able to create a "loose package" that can be sent
to someone etc, is part of the above. I just want to say that the model
in SM is quite interconnected, so these things aren't trivial to do if
we want to keep some of the current features of SM. But again, I am
interested in solving this somehow too.

3. Dependencies. I have said it before and don't want to sound like a
broken record :), but I do have a working implementation in my dev
image. I need to fix a few things and put a few UIs on it. I also should
describe the implementation so that you can give feedback.

4. Universes. I intend to look into Lex's code again more carefully and
try to figure out how to either:
	a) Make it work "with" SM. But this is only interesting if Lex or
someone else wants to continue maintaining Universes and nor merging it
with SM.
	b) Merge the concepts and mechanisms with SM so that the sum is greater
than the parts.


Phew. Ok, now I read the final post from Avi again and... well, I still
wonder a bit about the "stake out first" contra "break out".

But anyway, a great start guys!

regards, Göran