Daniel,

I lost your proposal in the "avalanche" of messages :)

Actually I don't know what is exactly Monticello... Where can I read about
it?  Avi, are you there?

Diego

> 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