Doug Way dway@riskmetrics.com wrote: [SNIP]
I posted some thoughts on possibilities for better tools here a little while ago:
Right. Just posted on the other thread before reading this. Duh.
I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc. I guess we could still use the term "harvesting" to cover all base-Squeak development? And we also have to consider package-level harvesting as the image gets split up into packages.
Agree. Harvesting is a nice word. And package-level harvesting is "of course" the way to go.
[SNIP]
Göran mentioned at one point that he and Luciano N. were looking at using a modified SqueakMap as the infrastructure for this, which I think might work. There are other ways it could be done. I'm not sure we want to stick with the Swiki method; it may be too limiting.
Agree.
In any case, we should get working on this, since 3.5alpha will be opening soon. Perhaps Luciano could get started with something based on SqueakMap 1.05, if we want to use SqueakMap as a base for this tool. (We definitely don't need to wait around for SM 1.1 for this.)
Right, no need for SM 1.1 for this. There are no changes planned in the underlying architecture.
If we have a basic submitting/annotating/voting tool working, we can use that as a starting point for refinement of the process, which can be discussed on this list...
If others want to actively help out with getting the basic tool going, feel free to volunteer here.
I will help out any way I can without actually doing it all myself. :-) I think this is a good plan - just a proposal for he/she who picks up the ball:
1. Look at SM, the code is pretty simple. Change it to suit the new domain. Use it to maintain the shared meta data about the assembly lines/FIXes etc.
2. Add a simple HTTP upload facility so that people can submit changesets into the assembly line easily from within the changesorter tools. I have code already for an HTTP upload server so don't write it again - I can whip up a changeset with it.
3. Pick one of the SM UIs and rewrite it to suit this tool. These new tools are pretty lean and easy to hack (instead of digging through the endless cruft of Browser and friends once again).
4. Let the tool use simple a simple HTTP protocol to issue "write operations" to the server. In a KISS fashion I would simply issue "Smalltalk evals" over HTTP instead of mucking about with SOAP etc. But that's just me - I like simple things with very little dependencies on other stuff. Remember that we are talking about a core tool for Squeak - it shouldn't require too much "other stuff" to work.
Well, there you go. :-)
rgards, Göran