[Squeakfoundation]Harvesting infrastructure (was Re: Order of business ...)

[squeakfoundation@lists.squeakfoundation.org]

Doug Way <dway@riskmetrics.com> wrote:
[SNIP]
> I haven't thought too much about how the back-end infrastructure might 
> work.  It could be based on SqueakMap or something else.
> 
> But we definitely want it to be automated so that 
> bugfix/enhancement/refactoring submissions are compiled somewhere with 
> no manual effort on our part.
> 
> One way to do this would be to simply require that people use a tool 
> (either a tool within Squeak, or a web form like with SqueakMap uploads) 
> to submit these submissions.  There would be additional benefits in 
> requiring that certain file formats and information be included with 
> submissions via such a tool (whereas the current submissions are kind of 
> a free-for-all, sometimes the formatting is bad, etc.).
> 
> I don't think this would be too harsh a requirement for the community.  
> An automatically-generated email could still be sent to the squeak-dev 
> list, so people would still see fixes/etc coming in.
> 
> Then we would want some sort of upload space to exist, maybe just ftp 
> space on squeakfoundation.org or something, where the submissions would 
> be stored.  The harvesters would need to be able to look at the list of 
> submissions, and be able to annotate them somehow as being "approved", 
> "rejected", or otherwise commented upon.
> 
> This is kind of sounding like something that SqueakMap would be able to 
> handle, with some customization.  It would be a separate catalog from 
> the usual SM packages, of course.  And the submissions themselves would 
> need to be stored somewhere.  But SM would perhaps be good for storing 
> the meta-info (annotations, etc.) about each submission.  A special UI 
> (different from SMLoader/SMBrowser) would need to be developed for the 
> harvesters to use to do the annotating, but it could probably start out 
> relatively simple.
> 
> Having both the submission tool and the harvesting/browsing tool within 
> Squeak would provide opportunities for cool functionality... e.g. my 
> ConflictChecker utility could be run on a submission by a simple 
> menu-click.
> 
> Or there might be other better ways to do this.  I'm just throwing 
> around ideas right now, and it's getting a bit late. :)
> 
> - Doug

I think that if we take the SM codebase plus it's two current UIs and
simply hack it a bit for dealing with FIX/ENH stuff then it would work
very good.

We can always have some "interconnection" between the two catalogs by
linking to UUIDs of packages. But you typically don't want to mix these
two catalogs together - they wil have different mechanisms and you
seldom want to load/look in both.

regards, Göran