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