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

Daniel Vainsencher danielv at netvision.net.il
Wed May 7 22:22:53 UTC 2003


Avi Bryant <avi at beta4.com> wrote:
> I wouldn't say it's immediately useful for what Daniel's proposing - the
> main problem is that it assumes all changes *can* be expressed
> declaratively, and I have a feeling that KCP and MCP changesets anyway are
> going to have some DoIts rather than just method and class modifications
> (but maybe that's not true?).  
We're talking about storing all ENH/FIXes posted to the list on it, not
just KCP/MCP stuff. Actually, the way they work is less of a hassle to
review their stuff.

As a temporary solution, if Monticello can let this application stuff
the doits in a comment (or two? preamble and postamble...), the reviewer
can decide to run it manually. Does Monticello handle everything else a
changeset can contain?

> However I am definitely willing to do what
> I can to make it work, if we can figure out exactly what's needed.

As I see it - the server creates a package for every unique message
subject (same rules as bug fixes archive uses). For every message with
the same name, create a version containing the code (might need to limit
to one changeset per message. Pretty raw. Ideas?), and associate with it
also the message subject, text so forth.

The UI needs to be able to access remotely, show the list of packages,
for each package show the code/diffs of all versions without loading it.
That's it, the first iteration. 

If reviewers can read the code for all versions of any posted fix
without doing more than picking it from a list, we're *way* ahead of the
game.

Daniel

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