On Thu, 2008-12-11 at 23:39 +0100, Göran Krampe wrote:
> Hey!
> 
> Ken Causey wrote:
> > I think Janko is misunderstanding.  I believe when Goran mentioned
> 'paid
> > people' he is referring primarily to Squeak Central in the early
> days
> > who of course were actively funded by Apple and then Disney.  More
> 
> Right, that was what I was referring to. More or less Dan and Ted
> IIRC.
> 
> > recently of course others have been able to contribute using time
> kindly
> > provided by their employers (Pinesoft comes to mind as an example)
> and
> 
> Mmmm, but not typically for harvesting, right?

True, good point.

> Anyway, my whole point is that it is best if we can find a process
> where 
> the "harvesting part" is minimized. Several of us have wondered if it 
> would be better to just have "commit rights" and then fix any
> problems 
> that arise from that - which would imply better tools to "back stuff 
> out" - which in turn points towards the idea of multiple streams etc. 
> (DeltaStreams and in some ways the mechanisms provided by
> Installer/Sake 
> etc).
> 
> For example - using Installer you can today point to a fix on Mantis
> and 
> install that changeset as a oneliner. So people can more or less
> "pick" 
> the fixes they think are fine. And if we add some kind of feedback 
> system into this then fixes could become "included" if enough people
> use 
> them.
> 
> Just thoughts. But the idea of having active "smart" harvesters 
> reviewing and integrating fixes from the rest of the community on a 
> regular basis is IMHO a tried and failed one.
>
> regards, Göran

Well my preference is to instead minimize what a harvester has to do for
each 'fix'.  Split what we currently refer to as harvesting into two
pieces: 1. the evaluation of the fix 2. incorporating the fix into a
release or release stream.

In my opinion a large number of people, an open group with no official
membership needed could perform the first step, the actual manual
testing and evaluation of fixes and record opinions for and against it's
inclusion into a release.

A much smaller group would serve as a final backstop and selectively
perform step 2 based on comments from the first group.  Ideally this
step would involve little more than an on/off switch (in the release/out
of the release) although with the addition of automated testing, maybe
seperate unstable and stable release artifact, the switch would have
more settings.  So a harvester is responsible for reading opinions but
then takes those at face value and if they read well, then flips the
switch on.  If the harvester at that point detects, via automated
testing, or just through personal use that this was a bad decision then
he flips the switch back off.

If someone else detects it was a bad decision they update the report
with the appropriate evaluation.  The harvester(s) should receive
notices of the report and this should trigger one of them to strongly
consider switching off the inclusion of the fix.

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/20081211/cd376e2f/attachment.pgp