Hi Ken,

Oops, you are right, I missed that in the last paragraph. So let me 
emphasize that I think it'll only work if you put actual trust in the 
maintainer. Having the maintainers as the guys who do the work but then 
get second-guessed at each step by a harvester is unlikely to work - it 
has too much of a feel of distrust to it. And I doubt that the harvester 
will be qualified to review that work to begin with - if he would, he'd 
be on the team itself, right?

The same about your initial oversight - you are sending the wrong 
message. You are saying you do *not* trust whoever is signing up for the 
work, and that means nobody will sign up. And if you want to influence 
how development goes, then why don't you sign up for the package? Seems 
to me that there is really no reason to "pull rank" by default.

Cheers,
   - Andreas

Ken Causey wrote:
> 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.
> 
> 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
> 
>