[Squeakfoundation]How to proceed for the kernel cleaning harvesting

[Daniel Vainsencher]

Hi Stef.

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.

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. 
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).
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.

Daniel

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> Hi doug and others
> 
> We are starting to make progress on the kernel cleaning. However I 
> would like to avoid to have 200 changesets to be included before 
> putting some of them in the stream.
> 
> What is important is that we are decomposing our changes (with pain 
> instead of doing three changes at once we really do them one by one 
> slowly) into
> small changesets so that people can understand them. We are also 
> building a testSuite
> that we will keep in the future as a kind of specification of what we 
> did. We are four working on that and we have our own internal 
> reviewing. We are also introducing a deprecation schema so that tools 
> build before the cleaning will be notified when they used an old method 
> and that people can query the deprecated method. This way we could 
> build a simple tool to identify deprecated methods and build a database 
> with that information for later migration.
> 
> Now the problem is that cleaning the kernel is somehow special and the 
> order of the changesets may be really important. So change 0001 should 
> be put in before 0004 for example. We are focusing on specific parts 
> and we have some major milestones as explained on the page. 
> http://minnow.cc.gatech.edu/squeak/3083
> 
> We can document what we are doing but if for every method move we have 
> to write 10 lines this will never scale. Normally there is a preamble 
> that explain the change but often we cannot spend time motivate them 
> because this is obvious. So I would like to know if some harvesters are 
> really interested in reviewing what we are doing, we are looking for a 
> meta-aware one. I asked Noury (the best meta programmer I know in 
> france father of metaclassTalk which already cure some part of the VW 
> kernel for his PhD) to be an external reviewer. But he is not an 
> harvester but could become one (Noury?)
> 
> So as soon as our own reviewing process will finish for the first 40 
> changesets we will send them into the stream. But we would like to know 
> how to minimize energy.
> 
> 
> 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
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation