Re: Harvesting infrastructure (was Re: Order of business ...)

On Saturday 16 November 2002 11:00 pm, Doug Way wrote:

> > What do you think the infrastructure should look like so we can
> > get a better process up? given Seaside and related technology,
> > I'm sure someone in the community could help us realize this, if
> > we can post a clear sketch of minimal, critical functionality for
> > a first release.
>
> 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.

I've been considering using Avi's new Repository stuff to grab stuff 
off the Squeak list (like sqfixes does), tag it with proper comments 
(like the message it was attached to), and then provide it to a 
separate UI. From there, it could be fixed by the community, or 
commented on (the UI could store approvals as comments).

There's no security structure yet in the Repository stuff, though. 
However, since the Repository keeps all versions, this isn't likely 
to be a problem.

> 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.

Or we could have a separate squeak-harvesting (squeak-fixes?) list to 
handle related traffic.

> 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. 

Or a remote Repository.

> 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. :)

Again, we need some kind of modeling of packages. Right now there are 
two that I have in my image:
* SqueakMap's card
* PackageInfo (previously a part of DVS, now separate).

I see these as being complementary; the SqueakMap deals with releases 
and finding them, and the PackageInfo deals with code.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE