links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Harvesting patches from Monticello repositories
Last updated at 11:59 am UTC on 17 January 2006
NOTE: This is not a currently implemented feature in the Monticello package, or anywhere else, as far as I know.

I've been thinking about this for a while. Here are some lightly-edited posts to the #squeak channel about this:

IRC conversation #1:

[09:33 (11/06/2003)] can I share my incredibly vague ideas
about next-gen harvesting with you guys?
[09:34 (11/06/2003)] well, the incremental next step is
per-package BFAV, with each package having its own archive
[09:35 (11/06/2003)] the big next step ( the very vague part ) is sharing "patch profiles"
[09:35 (11/06/2003)] totally distributed
[09:35 (11/06/2003)] some kind of file that publishes "here is
a patch for package X and here are the test results"
[09:36 (11/06/2003)] so I could see all of the patch-profiles
published by Ned Konz for Morphic, for example
[09:36 (11/06/2003)] basically each Squeaker could publish
their own bug-fixes archive
[09:37 (11/06/2003)] definitely thinking along the lines
of where Monticello is going
[09:37 (11/06/2003)] No - it sounds a bit like SMResources etc
[09:37 (11/06/2003)] also some SM2 stuff
[09:37 (11/06/2003)] Oh, the "no" was for the "gibberish" line.
[09:37 (11/06/2003)] well, it would make getting into "it"
easier.. I still have a patch for ClockMorph lying around here for a
pretty long time (nothing important, just 24h display)
[09:38 (11/06/2003)] An SMResource in SM2 is owned by an account and associated with an SMPackageRelease/SMPackage.
[09:39 (11/06/2003)] it would be cool to automatically see the "health" of a patch
[09:39 (11/06/2003)] is a package's tests more green after the patch is applied, according to the profile anyway
[09:40 (11/06/2003)] that's not really the metric imho -
fixing two bugs by triggering a third... :)
[09:41 (11/06/2003)] well, sure
[09:41 (11/06/2003)] the point is not for the profile to claim to be super-authoritative
[09:41 (11/06/2003)] just to give a rough idea
[09:48 (11/06/2003)] I'm just thinking about the problems of a bug / fix /enh database
[09:48 (11/06/2003)] and the problem of getting reviewers
[09:50 (11/06/2003)] basically, how could we switch
perspectives from "patch reviewing is a chore that dedicated citizens
should do" to "here is a neat way to find good patches for the package
you're interested in"
[09:51 (11/06/2003)] smakbo: I want packages to have an
"incoming" and an "update stream".
[09:51 (11/06/2003)] Incoming is unsorted, unreviewed etc. But
people can still see them and pick among them etc.
[09:51 (11/06/2003)] And the queue length is clearly visible.
[09:51 (11/06/2003)] right, that's one way to do it
[09:51 (11/06/2003)] my thought is instead of having a central "incoming" queue
[09:51 (11/06/2003)] Updates can be used - but normally people
just take the next release instead.
[09:52 (11/06/2003)] have a way to discover and aggregate
distributed "incoming" queues
[09:52 (11/06/2003)] discover/aggregate/evaluate
[09:52 (11/06/2003)] I didn't mean "central". :)
[09:52 (11/06/2003)] heh
[09:53 (11/06/2003)] The discover/aggregate part is already
"solved" by SM.
[09:53 (11/06/2003)] how?
[09:53 (11/06/2003)] Well, I may be misunderstanding what we are talking about but...
[09:54 (11/06/2003)] SM2 publishes a location where patches
can be sent?
[09:54 (11/06/2003)] smakbo listens
[09:54 (11/06/2003)] ... in SM2 anyone with an account can
register a resource (think patch) and associate that with ANY package
or specific package release.
[09:54 (11/06/2003)] smakbo hm
[09:55 (11/06/2003)] smakbo interesting
[09:55 (11/06/2003)] smakbo thinks about it
[09:55 (11/06/2003)] So the SMResource either contains a URL to
the actual content (in this case that seems likely) or has the actual
contents embedded right inside the map. Embedding only works good for
small amounts of data.
[09:56 (11/06/2003)] If the resource contains the URL then the
actual file can be uploaded to the file area on the SM2 server.
[10:01 (11/06/2003)] Anyway - the good thing with SM is that it
is a synchronized "database" in which we can stuff in things.
[10:01 (11/06/2003)] nice
[10:01 (11/06/2003)] So other apps like BFAV could use it as a
kind of "meta data back end".
[10:02 (11/06/2003)] By attaching stuff to packages/release as
[10:02 (11/06/2003)] yep
[10:02 (11/06/2003)] ok that will be very cool
[10:02 (11/06/2003)] But that is just the discovery part.
[10:03 (11/06/2003)] And aggregation.

IRC conversation #2:

[10:07 (11/07/2003)] then I've got this vague, wooly-headed
idea for going totally decentralized with patch-harvesting
[10:08 (11/07/2003)] but I'll get BFAV2 out the door before I
start fooling around with that
[10:08 (11/07/2003)] hmm, more input...
[10:11 (11/07/2003)] well, in going through feedback to the
BFAV, I see a couple of things
[10:12 (11/07/2003)] 1) it's hard to navigate lots of patches
[10:12 (11/07/2003)] 2) even when I find patches for packages
I care about, it may seem like a chore to pick through them
[10:13 (11/07/2003)] there are ways to deal with both of those using a centralized approach (better client UI)
[10:14 (11/07/2003)] but I have been thinking about a simple
file format, what I'm calling a "patch profile", that is published to
each Squeaker's personal repository
[10:14 (11/07/2003)] and contains helpful data about how
harvest-worthy the patch is
[10:16 (11/07/2003)] in this scenario I would be able to
browse to Ned Konz's repository and see his patches for, say, SkipList - but the patch-profile info would help me jump-start the process of
evaluating the patch
[10:16 (11/07/2003)] then in turn I could publish a
patch-profile in my repository that links to Ned's
[10:16 (11/07/2003)] Let's see if I'm getting it -
[10:17 (11/07/2003)] Each user keeps his patches on a server
[10:17 (11/07/2003)] He attaches some evaluation of it in a patch profile, also on his server
[10:17 (11/07/2003)] each reader gets all patches from different
servers, including patch profiles, and uses that information to sort
among them.
[10:18 (11/07/2003)] Right?
[10:18 (11/07/2003)] pretty much - although the client
wouldn't try to discover all patch-servers everywhere
[10:18 (11/07/2003)] I think it would be more like an
news-aggregator approach where the client would build up a subscription list
[10:19 (11/07/2003)] SM2 comes into this
[10:19 (11/07/2003)] if I understand Goran correctly
[10:20 (11/07/2003)] where I could publish to the SqueakMap
server an SMResource associated with a given package
[10:20 (11/07/2003)] so SqueakMap could be used to do
[10:20 (11/07/2003)] That makes sense. Another thing that occured to me is that it might be better if the patch evaluation code is on a server somewhere, instead of on clients, because then we don't have to depend on people updating their software to get reliable info about the code.
[10:21 (11/07/2003)] probably so
[10:21 (11/07/2003)] Sort of like I run a test server on my
machine, so people see what bugs live, and its always on the latest