hi daniel

Yes, we want to have a process that supports the energy we put in. So 
we will go slowly
bit by bit with tests, reviews....

Stef

On Wednesday, March 5, 2003, at 10:50 PM, Daniel Vainsencher wrote:

> Hi Alex, SCG, I'm glad you did decide to take this role, and start the
> KCP.
>
> I think these sort of focus, group projects can be a very good thing 
> for
> Squeak, in that they can create a good process locally, and let more
> people participate, and spread all sorts of knowledge among their
> members.
>
> And with good integration with the overall process, they can help
> improve our "visibility" and "speed". By visibility I mean that 
> everyone
> knows what progress has been made, for each package, how it is 
> regarded,
> and how close/far it is from being accepted. By speed, I mean getting
> more enhancements generated, with more of them accepted with fewer,
> faster cycles.
>
> I think these projects help because they set their standards internally
> (use SLint, use RB), list their specific goals in their specific 
> domain,
> for the community they serve as a source of focus on a subject (if I
> think something is wrong with the kernel, I know who to propose the
> change to), and for us Guides it should provide a single point of
> contact to "negotiate" strategy with.
>
> When the MCP started, I posted a mail to provide guidelines on how to
> most effectively get the process started, which I think apply here too.
> The important part is the results - tested, documented changes, in 
> small
> bites, that have had more than two pairs of eyes review them. Do you
> agree these apply to your project?
>
> Daniel
>
> **************************************************
>
> I propose you get someone from the team to review your changes, first 
> to
> see if they have improvements, and also to document them (as you did)
> making sure to explain why every kind of change done is acceptable (for
> example, "refactored #initialize" -> "replaced assignments to color 
> with
> implementations of defaultColor, and..."). This stage makes it much
> easier for us to accept what you did, but also documents the insights
> you've had. Also make a list of affected subsystems. Creating these
> detailed summaries will help the knowledge spread around.
>
> If the changes included several unrelated kinds of changes, it's better
> to split it into several changesets, each with it's own documentation.
>
> Then comes testing. Take the subsystem list produced above, and have
> someone test each one, and document that it's fine (so you can make 
> sure
> you've tested everything). The test doesn't have to be a complete 
> stress
> test - but it has to check the aspects affected by the changes made.
> Changed how the colors get assigned? bring it up and make sure it looks
> right. Other changes might require using the system in the appropriate
> way. It's important that someone other than the author do the testing,
> and that they actually exercise the changed code.
>
> When it's reviewed and tested, make it an ENH, and include all the 
> above
> information, and everyone that touched it.
>
> To summarize:
> * Make CS.
> * Review (what was changed, why, what's affected)
> * Split if needed.
> * Test (everything affected, according to specific changes)
> * Post as ENH
>
> BTW, as Stef says, sometimes the best documentation is a test. For
> example, if you find that Morphs should never assign to color in
> initialize, because that's actually ignoring the frameworks way of
> setting colors, make a SUnit test (in this case, maybe using SLint 
> rules
> like GermanM's). That way next time it will be caught earlier.
> **************************************************
>
> Alexandre Bergel <bergel at iam.unibe.ch> wrote:
>>> Software Composition Group guys, does one of you want to be the
>>> maintainer?
>>
>> The SCG group in Bern proposes to the community to be maintainer of
>> this set of classes. As direct responsible, I propose myself 
>> (Alexandre
>> Bergel).
>>
>> The first steps would be:
>>    - to set up a web site as it exists for the Morphic Cleaning 
>> Project
>> (MCP: http://minnow.cc.gatech.edu/squeak/3005)
>>    - to extend the unit tests that exist (thanks Andreas) with new 
>> ones
>> covering the rest of the functionality
>>    - to precisely identify issues and how to correct them
>>    - to maintain a list of fixes (the ClassBuilder one proposed by
>> Andreas will be one of these)
>>     - to be responsible for including changes from other people, fix
>> bugs identified by people
>>     - to decide what gets in a release and what does not.
>>
>> If this proposition is accepted by the community, the basic
>> infrastructure will be set up as soon as possible, and a mail 
>> describing some issues will be sent soon.
>>
>> We invite everybody competent to join. Noury, we want you :)
>>
>>
>> Cheers,
>> Guy at Bern
>>
>>>
>>> -----Original Message-----
>>> From: Andreas Raab [mailto:andreas.raab at gmx.de]
>>> Sent: Friday, February 28, 2003 10:49 AM
>>> To: 'The general-purpose Squeak developers list'
>>> Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4
>>>
>>>
>>> Brent,
>>>
>>> I would appreciate if you could take me out as the "maintainer" at
>>> SqueakMap. I'm not going to maintain any of this in honest. If you'd
>>> like to
>>> be the maintainer of a suite of tests for ClassBuilder feel free to 
>>> add
>>> yourself.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>>> -----Original Message-----
>>>> From: squeak-dev-bounces at lists.squeakfoundation.org
>>>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>>>> Behalf Of Brent Vukmer
>>>> Sent: Friday, February 28, 2003 2:40 PM
>>>> To: The general-purpose Squeak developers list
>>>> Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4
>>>>
>>>>
>>>> BTW, I installed the MetaClassBuilderFix SAR in a 3.4gamma
>>>> image, installed the ClassBuilder test suite, and then ran
>>>> the ClassBuilder test suite -- 3 out of 3 tests passed.
>>>>
>>>> -----Original Message-----
>>>> From: Brent Vukmer
>>>> Sent: Friday, February 28, 2003 8:32 AM
>>>> To: Squeak-Dev (E-mail)
>>>> Subject: ClassBuilder fix, SqueakMap, and releasing 3.4
>>>>
>>>>
>>>> Andreas's fix for the ClassBuilder bug is now on SqueakMap.
>>>> So is the suite of unit tests that Andreas created to test
>>>> ClassBuilder.
>>>>
>>>> On the docs side, I've created the following chain of Swiki pages:
>>>> "Documentation"->"Known Bugs"->"Known Bugs in 3.4"->"Adding
>>>> instVar to ClassDescription breaks ClassBuilder"
>>>>
>>>> We have SqueakMap fix-love and Swiki documentation-love for
>>>> the bug.  Let's roll with the 3.4 release.
>>>>
>>>> Cheers,
>>>> Brent
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Bergel Alexandre  http://www.iam.unibe.ch/~bergel
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
Prof. Dr. Stéphane DUCASSE (ducasse at iam.unibe.ch) 
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