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

[Ned Konz]

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=20
off the Squeak list (like sqfixes does), tag it with proper comments=20
(like the message it was attached to), and then provide it to a=20
separate UI. From there, it could be fixed by the community, or=20
commented on (the UI could store approvals as comments).

There's no security structure yet in the Repository stuff, though.=20
However, since the Repository keeps all versions, this isn't likely=20
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=20
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.=20

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=20
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=20
and finding them, and the PackageInfo deals with code.

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