I would like to reply to all the points in all.
  Andreas I think that the point you raised is correct however
here are some points to consider:

	- We always payed attention not to break (there are lot of changes
	that were never integrated just because of that)
	I can tell you that we have always in mind people making their  
living with Squeak
	the ones that earn real money because they build systems for real  
customers.
	So we are not just academix, daily I talk with netstyle guys and we  
do our best to
	help all the small shops around to make money with Squeak.

	Insulting people never helps (even if they are idiots they have memory)
	I can tell you that when your call us random refactorers we were  
really pleased.
	I wondered why I was pushing squeak. 	Marcus just dropped because he  
was SICK.
	Of course this does not mean that we have the right to do anything and
	we did not we payed attention not to break but indeed we have failed  
in some points

	Been a victim is always easy (even if this is good that you raise  
this **important** question
	this is important since we are always thinking about it: else we  
would not have push
	unit testing, writing article to educate people on that, pushing a  
lot of engineering tools
	such as a good test coverage testing tool and may be soon a test  
server).

	Now did you compute the ratio of changes and the numbers of problems?
	Because your noise ratio should also be computed: is it 1 on 5000  
changes? 1 on 2?
	What are the tradeoffs/how much? What is the overall quality  
improvement?
	How much tests did we bring inside the system?
	How much bug fixes? If changes would be for less quality this would  
be really a HUGE
	problem to me.

	Of course we made mistakes like letting people introducing wrong  
dependencies.
	I think that we lack some integration analysis tools: to compute the  
interface per client
	but this is difficult.

	- For some changes we let diego pushed his changes because we wanted  
to avoid
	forks, and this is our big mistake. We should have say to Diego that
	what he was doing was cool but that we could not integrate and let him
	grows his own basis until the point where we cannot communicate  
anymore.
	Because nobody would have reviewed 600 k of changes. Or this would have
	been taken 2 more years and everybody would have been frustrated:  
but may
	be having a not moving community is also a goal.
	
	I will talk with him this week about that face to face.
	Apparently this is a common strategy, when I see that SqueakLand was  
not really
	communicating with one of his biggest believer. It was fun to see  
the rush to
	do a fast track 3.8 as soon as we announced that we wanted to push  
in Squeak
	his changes. I understand that people should control their software  
basis, hence
	I understand iSqueak and all the rest.

	- A good way to make sure  that changes
	happen in the way you do not like is to say nothing during months
	and just complain at the end. Of course, you did not have the time (and
	we are so "random refactorers" that we have so much time doing  
nothing).

	- All in all I think that migrating to the changes after a year
	(because 3.9 started more than a year ago) is fair, especially if  
you have no time before.
	There is nothing like a free lunch and some stuff should be changed.
	
	- I think that we should have more tests and interface checking at  
package level
	if this is possible (I have no idea) and this would help us.

	- I think that the general solution to all these problems is  
certainly what we will
	do in the future. Create our own fork like that everybody will get a  
stable
	immutable version, and this will fit well the plans of certain people.
	Because this situation is not satisfactory for us too. We would like  
to move much faster
	and deeper. So we will count our forces and see what we do after 3.9.

	- After you can say a lot on 3.9 and a lot of negative points:
		we used MC (and this is slow xxxxx)
		this is bigger than expected
		...
		this is all true
		we take responsibility for that and we would have loved to do it  
better
		but so far none of us is payed to work on any squeak projects.
		So giving the context, the constraints I think that we did well
		it does not mean that we cannot improve but we did well.
Stef