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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20051012/e8a2697b/attachment.pgp