How to proceed for the kernel cleaning harvesting

Hi Daniel

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 
your
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 
understand perfectly)).

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
stream."

"
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 
problems
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."

OK



"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 
week)

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.


Stef



Prof. Dr. Stéphane DUCASSE
http://www.iam.unibe.ch/~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 
earth" Calvin&Hobbes

"The best way to predict the future is to invent it..." Alan Kay.

Open Source Smalltalks: http://www.squeak.org, 
http://www.gnu.org/software/smalltalk/smalltalk.html
Free books for Universities at 
http://www.esug.org/sponsoring/promotionProgram.html
Free Online Book at 
http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html