Indeed but where is the integration with Mantis? Nowhere right now. 
While writing a simple test is still a 1 min effort.

Stef

On 18 sept. 04, at 18:54, Brad Fuller wrote:

> It sounded to me that Alexander understood the issue you explained and 
> proposed a process that included a way to alleviate your issue.
>
> stéphane ducasse wrote:
>
>> Sorry alexander
>>
>> you miss my point, my point is not about the process of harvesting. 
>> My point is about
>> recording in executable manner knowledge about the system. This is 
>> not linked to any bureaucratic
>> mechanism. People are crying that there is no documentation about 
>> squeak, then they build big plans,
>> then NOTHING happens but they talked and talked and talked. While 
>> writing a 1 min test is a small
>> but a real tangible step in that direction, and in addition I can 
>> understand it.
>>
>> Have a look at the test of UUID, you do not need to be an expert to 
>> understand them and everybody can write
>> tests like that.
>>
>> Just for your information, I started to harvest without BFAV and this 
>> is a HUGE improvement.
>> Still, just uploading a single file in the update stream is painful, 
>> marcus is working on that.
>> We have to check conflict, updload file, rename cs...
>>
>> Now people can talk hours about x or float precision, if at the end 
>> we do not get
>> code with tests, then we all lost our time.
>>
>>> Hash: SHA1
>>> Although I'm on a strict eMail diet I can't resist to write a short 
>>> note:
>>>
>>> Did you ever play the Infocom game ``Bureaucracy, A Paranoid 
>>> Fantasy''
>>> (written by Douglas Adams)? Sometimes I think the harvesting process
>>> is a remake of that textadventure. "Tag it with [ZORK], compress it
>>> with KNORTZ but never with KNORZT and send it to the BFAV. Then ..."
>>> You can't blame people for not loving bureaucracy. If the harvesting
>>> is not working than it is the process that is flawed!
>>>
>>> To be a bit more positive here just a quick thought that may or may
>>> not work:
>>>
>>> How about we move all the bug reports, fixes and suggestions for
>>> enhancements to the mantis server? Then a casy study could be like 
>>> this
>>>
>>> - - user creates a new report with the serverity *feature*
>>> (=enhancement)  describes the enhancement and attaches the code. Now
>>> the user knows that his thingy got registered somewhere and does not
>>> silently dissapear in a mail archive....
>>>
>>> - - harverster looks at this entry later on, sees that no test is
>>> included and puts this report on hold (=feedback) and adds form Z9 to
>>> the report
>>>
>>> Z9:
>>> "Your enhancement was put on hold because we decided to only accept
>>> new enhancement if they include a minimal test. Look here for an easy
>>> HowTo for writing unit tests and ...." (this gets automagically 
>>> mailed
>>> to the reporter)
>>
>>
>> It may work.
>>
>>>
>>> - - user reads the mail and now knows that somebody looked at his
>>> stuff(!) and that there is a problem. If he cares about the thingy I
>>> bet he will go the extra mile and provide a test.
>>>
>>> - - next harvester sees that there is now a test for the enhancement,
>>> changes the status of the report to whatever, test the thingy and can
>>> add a note that appoves or declines it
>>>
>>> I think when to reject or to hold a report should be briefly layed 
>>> out
>>> in some kind of policy doc that should be agreed on once (by the
>>> harvesters?) and placed on a swiki for public notice.
>>
>>
>> We said that several times, already.
>>
>>> A sender of a mail that shows up in the mailing list with a subject
>>> tagged with [(ENH|FIX|BUG|GOODIE)] should get (once) an auto reply
>>> which tells him to use mantis. This auto reply should of course
>>> include form Z9'.
>>>
>>> Alex
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.4 (MingW32)
>>> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>> iD8DBQFBTA8rYiF2wSTEZ9gRAgPcAJ9odFI4Ncu2NSb8xAAhl/VwkpvKpgCdGajn
>>> 4b8AQ1BBSCREfCXxCwhpheM=
>>> =2qsb
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>
>>
>>
>>
>