On Wed, 16 Oct 2002, [ISO-8859-1] G=F6ran Hultgren wrote:

> A sidenote: One reason for the Modules work being so... uncoordinated is =
the
> lack of a good "CM" tool like CVS or similar. Would you say (I trust your=
 word)
> that DVS is the best thing going in this respect for Squeak currently? If=
 that
> is the case, then perhaps we should consider using it for all the
> Modules-related cooperative work that needs to be done in 3.3. Currently =
there
> are a whole slew of .cses floating around that needs to be integrated etc=
=2E The
> lack of something CVS-ish (and I am talking about the very simple
> update/commit-cycle) is IMHO a big hurdle for real cooperative developmen=
t in
> the Squeak image and the Modules area is a good example where we really n=
eed this.

Yes, I would say that DVS is the best thing currently going (the only real
alternative I know of is CVSTproj, and DVS is much more usable currently).
However, DVS is aimed squarely at 3.2 - I have no idea if it makes any
sense at all in a 3.3 context, so doing work on the 3.3 modules with it
may be a non-starter.  You'll have to tell me.

> > Daniel has already done 5, again in 3.2.  I don't see why 6 would be
> > very
> > difficult - it ties into what Daniel and I were talking about with
> > subclasses of Module to store metadata.  6 also seems like something
> > that
> > SqueakMap might be extended to do.
>
> True but I have steered away from that since I didn't want to duplicate e=
fforts
> - Modules already has functionality for it.
>
> It would be a pity if people started to "rebuild" stuff (that is already
> implemented partly in 3.3 Modules) in 3.2 instead of helping out and fini=
shing
> the job in 3.3...

Well, it not only would be a pity, it *is* a pity, because that's exactly
what's happening.  I avoided for a long time doing anything that seemed
like it was duplicating the 3.3 Modules, but here's the problem: I need
this functionality *now*, and I need it to work with all the Squeak tools
I currently use.  Reimplementing the 10% of the module system I needed in
3.2 was *way* less work than finishing the 3.3 module system + getting all
the current 3.2 tools I need updated to work with it.  IMO, if a module
system is going to get accepted, it's important that a) whatever features
it has work, and b) it's backwards compatible.  That way people can slowly
migrate to it, rather than freaking out because it's currently too broken
to work in.  Incrementality is the key here.  I realize there may be
people for whom this isn't true, and so much the better, but for me:
there's no chance I can give time to working *on* a version of Squeak that
I can't also work *in*.

> > 7 is, of course, the big one: it is the real justification, as far as
> > I'm
> > concerned, of the work that's beem put into 3.3a.  But how big a deal
> > is
> > it?  Are people routinely struggling with naming conflicts?  I tend to
> > throw a 2 letter prefix in front of my class names and forget about it.
> > But maybe that's just me.
>
> I agree but if you have read the Swiki pages about Modules you realize th=
at
> there are a lot of cool stuff there. The ability to separate loading from
> activation, working on different versions of classes/modules, clean atomi=
c
> stages of downloading all dependencies, loading them all into the image a=
nd
> finally activating it all, the global namespace and so on.

Sure, that stuff's all extremely cool.  The problem with 3.3 modules is
not necessarily technical, but social: I'm beginning to repeat myself, but
I'd be much happier with a tiny subset of that *that people actually
used*.

Cheers,
Avi