> I don't insist on that, I even touch on the idea of 'bypassing' the
> Harvesters at the end of the second paragraph.  However I think we  
> need
> to take this all one step at a time.  Maybe some Stewarding teams  
> should
> be given direct access to the update stream from day one.  I'm  
> certainly
> not against that.  However I think that for any new team a little
> initial oversite should be the default and as they build up confidence
> the reins can and should be loosened.

Exact and having more tests could help.

> Ken
>
> On Wed, 2005-10-12 at 10:49 -0700, Andreas Raab wrote:
>
>> Hi Ken -
>>
>> Sounds almost like what I was saying but you still insist on
>> bottle-necking it through a "harvester". Why is that? Do you feel you
>> need a harvester for anything Avi or any of the guys working on
>> Monticello do? On VMMaker? If not, why do you feel you need a  
>> harvester
>> for, say, the FFI, the Graphics subsystem, Morphic, Sound, or
>> Networking? Who, if not the people working on this part of the  
>> system,
>> could possibly decide what an appropriate resolution of the issue  
>> would
>> be? When you have responsible maintainers there is simply no role  
>> for a
>> harvester per se - there might be some supporting roles (like
>> classifying bugs or integration testing) but all of these issues  
>> should
>> be handled by the people developing the package, not some guy who  
>> is in
>> control of everything[*]. For some reason even you guys who talk  
>> about
>> decentralized development and stewarding then like to fall back on  
>> total
>> centralized control.
>>
>> [*] Making releases then means that you have someone who is charge of
>> integration testing and writes bug reports for the packages in the
>> release which get addressed by the people developing that package.
>>
>> Cheers,
>>    - Andreas
>>
>> Ken Causey wrote:
>>
>>> In my opinion a big (HUGE) step in the direction towards  
>>> improving this
>>> situation is developing the Stewarding system where teams take
>>> responsibility for image categories and packages.  The idea here  
>>> is that
>>> for any given class in the system there is a dedicated person (or
>>> hopefully group) that has accepted reponsibility for it and has
>>> undertaken to become an expert on it.  We call such a person a  
>>> Steward
>>> and the team under him or her a Steward Team.
>>>
>>> The Harvester's job is then reduced whenever an issue appears  
>>> related to
>>> this class.  The Steward(s) for the class will handle the issue  
>>> and come
>>> to agreement on the appropriate action.  Once agreement has been  
>>> reached
>>> they will hand off a complete and ready solution to the  
>>> Harvesters.  The
>>> Harvesters then can have confidence in the solution (built up  
>>> over time
>>> because they have developed confidence in the Steward(s)) and can  
>>> give
>>> it some quick automatic checks and shove it into the update stream
>>> (whatever form that happens to take).  In time once the  
>>> Harvesters have
>>> built up enough confidence in a particular Steward team perhaps that
>>> team can simply inject fixes directly into the update stream and not
>>> require any time from the Harvesters.
>>>
>>> Right now Goran and I are spiking the day to day business of  
>>> Stewarding
>>> and trying to work out how it will work on the lowest levels.  I  
>>> really
>>> hope that by the end of the week I will be able to produce a  
>>> document
>>> explaining the concept in detail and what it entails and once  
>>> more call
>>> for participation by the community.
>>>
>>> More soon....
>>>
>>> Ken
>>>
>
>
>