fix-finder tool (was Re: Convincing a harvester (was on SqF

Daniel Vainsencher danielv at netvision.net.il
Wed May 7 21:38:51 UTC 2003


Actually, the KCP MCP project already provide their changes in a form
that's pretty convinient, for a specific project. Seems to me that the
main issue is adding something that works with our existing system of
posting stuff on the list, and builds on that to let all review that
easily.

Did you see this sketch I posted before? What do you think? The big
advantage is that by being based on a real code management
infrastructure, it would be a good basis for lots of further integration
and automation work later. Could become the main repository where SM
packages actually are stored.

*************
Hmm, we already have the start of a change management system, maybe this
can be it's first UI.

- make something listen to the list [could be based on the existing
bug-fixes archive by BertF], 
- add each changeset as a Monticello package with the rest of the
message text as a comment on those. 
- Enable the remote repository access stuff enough that people can "get"
stuff.
- A simple specialized UI that gets bunches of updates the monticello
repository.
- For the rest of the review tool, use OSProcess to open a clean image
with the chosen set of changesets loaded.

Avi, what will it take for the Monticello side of this? can you do it?
*************

Daniel

diegogomezdeck at consultar.com wrote:
> Tim and list,
> 
> > <diegogomezdeck at consultar.com> wrote:
> >
> >> Let's talk about wich tools we need to make the process smooth. I
> >> offer to program it.
> > Good man!
> >>
> >> Initial set of features:
> >> - publish a changeset to the "repository"
> > I think this is partially covered already; by mailing a changeset to
> > the list the sqfixes filter already grabs it and 'all we need' is a way
> > to treat the results as a convenient repository. I'd claim that the
> > current format is not too convenient because you get huge lists and
> > little navigation support to help one find any interesting or relevent
> > entries. My theory is that we can do better and that possibly using the
> > FTP access already available would be good. Another possibility that
> > has just occured to me is that a variation of SM would have some
> > virtues. Instead of simply installing any change (danger!) it would
> > fetch the whole bundle of messages and changes associated with a
> > bug/fix/enh.
> 
> I was thinking about using a swiki page.  This page is *only* changed from
> squeak.  In this way we can continue working in a similar way that MCP/KCP
> but much more automatized.
> 
> The squeak will parse and modify the page based on the features we're
> talking about (changeset, comments to it, fixes to it, etc)
> 
> What about that?
> 
> Will the HTTP and the HTML stuff removed from the base-image?
> 
> Diego



More information about the Squeak-dev mailing list