Hi Michael

Ok today I stop my strike from Squeak-dev and I will see if I can help 
harvesting again.


I just want to say a word there because I was a bit surprised by your 
email (still understand it).

- Monticello is not henryk module
	(you know that ***we*** were some of the fews that really tried to 
understand and push henryk modules)
	monticello is really close to ginsu (joseph will never deliver 
anything but this is another story).

- Can you tell me what you do not like in monticello. (I have a list of 
things that I do not like
	especially the lack of dependencies but avi has a first solution). I 
think that giving feedback
	is important for avi and the rest of people.
	
- What I see is that we need a way to express (yesterday I read some 
email of the old mailing list on modules)
	load code
	load dependent code
	load ***atomically*** code
	be able to say that a method is belonging automatically to another 
changeset (not like it is done now)
	we need a real representation of what is happening in the system and 
changesets do not support
	that (ask alex about the mess we got to split our KCP changes in 3.5 
so that they could be put in 3.6,
	may be this was our mistake we should have jsut do not care at all of 
squeak and just steal what
	could be stolen there. I know you contribute! so this is not against 
you but I have to argue with people
	here so that they spend time to make sure that their changes are not 
lost.)
	loading bytecode (alex already did some experiences with that)?
	
- Changesets are hopeless to build robust process.
      Ask nathanael the mess we got because they only record changes.

- So I'm not saying that we should have a packaging system in the image 
but
     this is with this kind of attitude that we are sure Squeak will 
stay where it is.
Do you have an alternative?

- Categories are a stupid packaging system, making categories real 
objects (packages)

- please note that I'm talking about module (with import and visibility 
here)
I just talking about identifying the right piece of code and its 
dependent.


On 27 janv. 04, at 00:35, Michael Rueger wrote:

> Doug Way wrote:
>
>> goran.krampe at bluefish.se wrote:
>>> PS. We did more or less decide to stuff Monticello into Basic - 
>>> perhaps
>>> it is high time now that SM2 is running?
>>>
>> We could, if the current version of Monticello is reasonably stable.  
>> We should at least put it on the to-do list for 3.7alpha if we're 
>> sure we want to add it.  http://minnow.cc.gatech.edu/squeak/3491
>
> I may be the lonely kid on the block here, but I'm against it on 
> principle. I don't use the Monticello for a variety of reasons, but 
> besides that I don't want *any* (can I double bold this?) packaging 
> system in the basic system.
> Packaging systems have the tendency to viral themselves into all 
> aspects of the core system and once they are there, nobody even has 
> the chance to come up with a different approach.

Have you some other approaches? Because for me maintaining a script by 
hand is ***painfull***
Does not scale.

>
> The total and utterly failure of the module system, from which we had 
> to back out as we couldn't remove it any more, taught us a lesson, 
> please let's remember it.

yes it was too ***complex*** and we are again one the fews that really 
tried.
monticello is no rocket science it is just a good and simple approach 
of the problem (like Ginsu was).

> I'm not saying that Monticello is not a usable (and hopefully at some 
> point stable) system, but packaging should not be built-in. Period.
>
> I like the SM approach, as it does not enforce a particular packaging 
> approach, but rather allows people to post their code in whatever 
> loadable format they want.

I'm not saying that we should have monticello in the image. but I'm 
saying that we should have a way
to get rid of the terrible mess of changesets, fileout:asHtml and other 
ugly stuff.

But apparently we are living in a perfect world.


>
> Michael