Doug Way dway@riskmetrics.com wrote:
Daniel Vainsencher wrote:
... [Status - everyone should know where each release stands. Could be solved with a bug/issue DB] You're right. We need such a tool, but - we need more urgently a fix tracking tool, to make sure we don't lose work that people submit - fixes are higher priority than bugs, because people become more upset when you lose their changesets than when you ignore their bugs.
We're planning to make such a tool, but we haven't made much progress in that, either. We could really use some help from the community with either of them.
I put together a swiki page awhile ago (which I just updated a bit) with some initial thoughts on how such a tool might work:
http://swiki.squeakfoundation.org/squeakfoundation/86
Feel free to add comments at the end of the page. I'm planning to start working on this as soon as 3.4 is released, but if anyone else is interested in helping out with this, that would be great.
- Doug Way
I have posted the following comment on An Improved Harvesting Infrastructure http://swiki.squeakfoundation.org/squeakfoundation/86
[Hannes Hirzel, 1-March-03]:
I do not think that the UI is the main problem. Even doing some manual editing work on a swiki table is not really a time consuming thing. The main problem is the process of assessing the quality of the fixes. And this is directly linked to the availability of SUnit tests for them.
As a concrete next step I would suggest approaching the problem from three directions
!! Harvesting process Tentative description of actions for Enhancing the bug and fix reviewing process
! Use case for harvester champion The gsug archive contains the fixes http://swiki.gsug.org:8080/SQFIXES/
# Write a little script that loads all the [Fix] tagged changeSets from the gsug archive into CodeBrowsers of a harvester champions flagship image. # run automated queries on the codebrowser to find out which class categories are affected. # generate sublists of groups of fixes - Smalltalk code that will load the fixes for other harvesters.
! Use case for general harvesters
# Run one of the sublists to load a bunch of code browsers with fixes # Have a quick assessment on the importance of the fixes. # Do a table entry in a swiki table describing the fix and assigning it a status. # Ask the authors and others to supply test cases. # Collect the tests, run them. # Update the swiki table regarding the status of the fix # Feed the fix into the update stream
!! Get more people involved in the reviewing and testing process.
Assign areas of expertise / responsibility to harvester champions. Why not have 25 harvesters with 5 harvester champions? Newbies are welcome as well - they know how to press the 'run all tests button'.
!! Get more applications / packages removed from the core Get more applications / packages removed from the core from the core so that the number of fixes diminihes.
Actively seek stewards for the various packages.
Question: Where is the link to the current harvesting infrastructure?
-------
Please ask questions if you think something is written in a style not easy to understand or is just plain wrong.
At the moment I think it is the best to update the swiki page and send a copy to this list as this is a very important matter. It actually deals with the way the Squeak community communicates regarding bugs, fixing them, assessing the quality of the fixes and finally including them.
I think that involvement of more people is needed. Doing this fixing process can't be the duty of just 5 volunteers!
-- Hannes Hirzel
squeak-dev@lists.squeakfoundation.org