Where we are going with partitioning and harvesting etc.
goran at krampe.se
goran at krampe.se
Tue Jun 21 13:00:01 UTC 2005
(cross posting since Ken's recent post touches on the very same aspects)
I have been re-reading the archive (=the packages team archive) to see
where we are and what I had promised to do. :) I am a bit unsire about
the latest development. I had my sights set on this (brief description):
- Get Universes and SM playing together. As promised by me to Lex and
- Use PIs to partition the image. The good ol TFNR idea, which Ken now
also expresses in his post.
- Tie the PIs to corresponding SM entries. This is key to get the full
connection to maintainers and their emails etc.
- Gradually move to maintaining these "image packages" as MCs "released
on SM", instead of using changesets in the stream. This part obviously
is different from the recent plans in the Package team.
- Add my planned dependency model in parallell with Universes. They in
fact complement each other quite nicely when thinking more closely about
Now it seems like the plan is to move to using something independent of
SM, which means I have no idea on how to proceed with the above. Perhaps
I am not interpreting the plan correct - then you all may of course
explain it to me and slap me. :)
I have also some serious doubts about schemes/models that depend on
"community work". With that I mean work "by" the community "for" the
community, eh, if you know what I mean - instead of work "by" yourself
"for" yourself. Hmmm, Ken has a much better english than me, but he is
essentially saying the same thing.
Harvesting is a typical example, an unselfish act for the good of all -
not directly connected to any personal immediate need. Or trying to
maintain a Universe, yes, I *do* have doubts about that model - but at
the same time I want to enable it - because I may very well be wrong :).
Or staking out the image, an act which has stalled numerous times for
that specific reason I think. All these activities have that in common -
they are "non individual" activities relying on community members to do
the work "for the benefit of all".
I have come to the personal conclusion that schemes depending on such
work have a high risk of failure in the Squeak community. We simply
aren't that good at it. We are much more individualistic and we like to
scratch our own itches, which means there are two things we are really
- Maintaining our *own* packages, typically driven by our own needs in
combination with pride and "feeling good" when other people appreciate
- Finding and fixing bugs in other Squeakers' packages but almost
always driven by our *own* projects/packages, we simply fix stuff we
So my view is that we need a system which relies on such individual work
only, or at least to 95%.
Ken asked "What are we waiting for?" and... I am not sure. The
PI-partitioning bit - which is key here - should simply "be done" IMHO.
I say let's get *a single person* to just do it and push a .cs into the
stream which creates the PIs. I was inclined to get Doug to do it (being
v3.9 boss and all), but I don't really care as long as someone does it.
Again, I am not sure how this plays with the latest plans/developments
(read the packages archive for details).
Ok, over and out.
More information about the Packages