Harvesting process (was: Re: [updates] 51 for 3.1 alpha)

danielv at netvision.net.il danielv at netvision.net.il
Wed Oct 3 15:20:18 UTC 2001


Wow, reading this message was strange...

Until the usual assume-misunderstanding training took over, I found it 
pretty scary. I really hope you can clarify.

Torge Husfeldt <jean-jacques.gelee at gmx.de> wrote:
> Dear Harvesters, Hi Daniel,
> I tought I just drop in oe or two thoughts on this subject:
> 
> Firstly I thought _becoming_ a Harvester don't seem so hard to do, it's
> the work itself that is the hard part (and thanks for that). So if you
> Celeste folk are really that interested in your stuff (and it seems to
> evolve very neatly) then why can't you just assign the job of a special
> 'Celeste-Harvester' to someone?! 
That's very near what I proposed - we harvest changes to Celeste and
integrate them continually, the Harvesters integrate our versions into 
the image.

> I think this is much more feasible in
> the near future than a dedicated repository (i may be wrong).
I don't understand this sentence. I've been maintaining the Refactoring
Browser on Hans-Martins SCAN repository, and I don't think he'll object
to adding another project. It's quite convinient, and the primary
Harvester could harvest a new version from there anytime they feel like
it, or we could ask them to include specific versions.

Some people seem to have it reasonable to try out the RB under this
arrangement, I expect this won't be problem for Celeste users either. If
other people have found this repoistory unfeasible, they're either too
polite or not interested enough to have told me (hard to distinguish).
 
> Secondly _please_please_please_ spare us (the list) with all of the
> comments why this_and_that code snippet was not included in the update
> stream. 
?!?! see below.

> I think the solution with the wiki-page is better than nothing
I agree, it's off to a great start.

> and _much_ better than the additional 'noise' on the list.
Noise? discussion in a mailing list that revolves around a piece of open
source software, on what code should go in a system and what shouldn't,
and what are our standards, and what happens to the code people
contribute sound likes prime-rib-steak signal to me.

What I think this list is about is a bunch of people playing around with
and actively evolving what Squeak is. And there's nothing that's more in
the core subject for this list than discussion about that.

If you think there is, enlighten me.

Daniel Vainsencher




More information about the Squeak-dev mailing list