On Thu, 9 Oct 2003, ducasse wrote:

> Between 3.5 and 3.6 some packages have been removed and alex did a
> changeset Splitter to move the change related to class in different
> packages automatically. however the fact that we do not have a complete
> representation
> of the model of code of Squeak (globals, category rename) then we edn
> up doing some stuff manually. Extremely fun to do and sure to lose
> changes and introduce bugs. We could easily imagine a system where when
> a changes is done, it is split automatically to the package where the
> concerned classes are located or to create automatically classes
> extensions to the current packages.

Stef, you've brought this up a few times.  Can I ask: have you *tried*
doing this using Monticello instead?  I'm not saying it will provide a
100% solution for what you're doing, but I suspect it'll bring you at
least part of the way there, and then we'd know what had to be done to
bring you the rest of the way.

> So if we are serious about having packages and maintaining when they are
> out of the image we should really consider have package entity (may be
> package info), support inside the image for class extension and may be
> based on something else that monticello *categories and a complete
> uniform code fileout that does not contain doit because wehn you do code
> analysis you do not want to have to parse string and to interpret their
> side effect. So may be this should be the goal for 3.8.

Again, Monticello already provides this kind of doit-less fileout.  Maybe
you'll run into some situations where you need something MC doesn't
support (you mentioned globals, for example), but at least then we'll
*know* that this needs to be added and we can work on it (and most of
these can be solved short term by cheating and using class-side
#initialize methods).  Right now you're just saying "changesets suck",
and, well, we know this already.  Please, tell us why Monticello sucks
instead.

> Now we have to decide. Avi would you be interested to have Ginsu as a
> core meta-model for monticello?

I suggested that to Joseph at StS, but the conversation didn't pan out as
I had hoped.  Right now, I'd say (if you'll forgive the reference to a bad
movie) "Show Me The Code": once there's a public, open source release of
Ginsu we'll be in good shape to evaluate such possibilities.  Until then,
let's work with what we've got, thanks.

My honest guess is that it's not something I'll be willing to invest time
in personally, but I'll provide support to anyone that wants to try.  I
don't think allowing MC to support multiple packaging/modelling systems is
an unreasonable goal.

Avi