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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
squeakfoundation@lists.squeakfoundation.org