[Squeakfoundation]How to proceed for the kernel cleaning harvesting
ducasse at iam.unibe.ch
Sat Apr 5 22:04:54 CEST 2003
Sorry I copied from the pipermail. Now I'm in the SqF list again.
"I see what you mean. You want to specialize the general process for
particular effort. If you bring your own external reviewer, (and I heard
Noury's talk last ESUG, so I have no doubts he can handle the meta
aspects) that makes things easier, you don't need to motivate other
external reviewers. Because he knows the context, he'll understand what
you're doing with less prompting."
This was not really my intention. I do not have any predefined idea. We
want to follow any process that we make sure that our changes are
evaluated in the best way.
Now the problem is that if we generated a set of changes and that we
have to wait that they are put into the stream to continue, this will
not work. We are working on some tightly coupled classes, one which it
is really difficult to make independent changes (Or we need a long
period of time).
Now what we want to know is how can we speed up the process because we
cannot allocate resources over a long period of time. At the end, alex
and nathanael will just fix the kernel for their PhD and this will be
lost for Squeak. Nathanael and alex already fixed parts for their
current work, noury did that too on his side. They are willing to
**redo** this (with the extra responsibility that it should really work
and be clean) which is a big effort. I cannot tell them go slowly
because Squeak need you. This will not work. This means that if the
process is not fast enough we may arrive to the situation were we will
just shared between us (the guus at berne + noury) which would be a
pity but a working solution for us (because at the end the kernel we
dream about is not the one we will do during the Cleaning Kernel
Project. We will do a kernel that allows us to build the one we dream
because we are not sure that people will accept our dreams (which I
Then another issue that the Guides/harvesters should consider is that
the Guys from Berne may not be available 100% on that in the future.
Roel just got today an excellent position (so he will have to teach,
build a team....) within six months, I may find one and have to teach
and create a new lab soon. Alex and nathanael will have to focus on
their PhDs. So during the next 4 months we are sure to have 4 meta
programmers and squeakers available at berne. But after that we will
start to be dispersed = less efficient = more busy.
I think that the Kernel Cleaning is the first big cleaning process so
what is really important for us is that **you** discuss internally and
you let us know if/how we can proceed to go fast with those changes. I
think that there are some opportunities but you have to understand our
constraints. My main points here is that I want to avoid frustration
(we learned from Squeak3.3a) and still would like Squeak to get better.
"It sounds like the front end of the process will be fine.
However, when you specialize a process, you need to make sure the
invariants are kept... here are the invariants we do need to
intelligently [approve] the changes, so they can get into the update
1. We might not approve a specific change because we don't agree with
the solution, or because we don't agree there's a problem. So, usually,
we request changes be independent of one another, so we can review and
accept/reject them independently, and evaluating their value by
themselves. If you make some changesets interdependent, we still might
not accept a changeset, and then it's your problem to work around it.
This might still work, because you're working with well defined goals."
That's why we started to work on the most obvious problems and let the
points were people could disagree at the end.
"2. If you want to help me make a positive decision, make it clear what
problem you're solving, and what design decisions you're making. I don't
need it to be ten lines per method - do the minimum, but communicate
your decisions clearly. Making the changesets small helps. When you mix
different operations in the same change set, it obfuscates (change set
11 converts Smalltalk -> self environment AND changes Behavior
interface, moving things to a new class)."
We paied attention to that at the extreme so normally this should not
be a problem. Up until now we only fixed trivial and obvious problems.
We will not start to
touch more conceptual problem before all the stupid, basic engineering
are into the image.
"3. An external reviewer is as valuable as his comments. An anonymous
[er] without the text of the review is meaningless. I want to SEE
Noury's comments. Why? I know perfectly well he's a brilliant
meta-programmer, but other than that, I don't know anything about his
criteria. And if he feels something is so-so, I want him to write it
down, so I can consider it too."
"If you keep these invariants, I'll do my best to review your changes
(and approve where appropriate) with reasonable dispatch - I think a
clean kernel would be a wonderful thing. And within those invariants, as
part of a specialized process, which I can agree to, we can change
almost any part of the "ceremony" you want, so you can save energy."
Ok so let us know. I think that making a try on the current changes
could help to tighten the process and see if we can work this way.
What I suggest is the following (depending on the availability of
Noury's and Roel's time there is a deadline for ESUG for the end of the
1. we proceed to an internal/external review as soon as possible.
2. we let you know.
3. you try to assess the changes as fast as you can and report how we
can improve communication.
4. If in the meantime you/harvesters evaluate the proposed changes
which are simple (the only design point is that we introduced a new
class for the navigation and UI related actions that the tools can
reuse), and accept them we just pass to the next ones.
Prof. Dr. Stéphane DUCASSE
"if you knew today was your last day on earth, what would you do
different? ... especially if,
by doing something different, today might not be your last day on
"The best way to predict the future is to invent it..." Alan Kay.
Open Source Smalltalks: http://www.squeak.org,
Free books for Universities at
Free Online Book at
More information about the Squeakfoundation