Tweak mainstream in Squeak
stéphane ducasse
ducasse at iam.unibe.ch
Tue Jul 11 07:05:51 UTC 2006
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
More information about the Squeak-dev
mailing list
|