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